1. Security Overview

2. Security Objectives
Confidentiality: prevent/detect/deter improper disclosure of information
Integrity: prevent/detect/deter improper modification of information
Availability: prevent/detect/deter improper denial of access to services
Farkas
CSCE 824

3. Distributed applications
Authenticity
Non-repudiation
Farkas
CSCE 824

4. Sample Questions
What is the trade off between the security objectives?
Give an example of the security objectives in the domain of college education.
Consider the trend about attack sophistication and intruder’s knowledge. Recommend an approach to enhance the security of future computing systems.
Farkas
CSCE 824

5. Achieving Security Policy Mechanism Assurance What to protect?
How to protect?
Assurance
How good is the protection?
Farkas
CSCE 824

6. Security Policy Organizational Policy Computerized Information System
Farkas
CSCE 824

7. Sample Questions
Why do we need to fit the security policy into the organizational policy?
Why is it recommended to separate policy from mechanism?
What does “assurance” mean in the context of security?
Give an example security policy enforced on your personal computer/CSE computing system/CEC computing system and recommend security mechanism to implement the policy.
Farkas
CSCE 824

8. Security Mechanism Prevention Detection Tolerance/Recovery Farkas
CSCE 824

9. Security Tradeoffs Security Functionality Ease of Use COST Farkas
CSCE 824

10. Threats, Attacks, Vulnerability, Risk
Types of threats
Types of attacks
Relation to security objectives
M(ethod), O(pportunity), and M(otive) of attacks
Methods of defense – Security planning
Risk Management
Farkas
CSCE 824

11. Risk Management Framework (Business Context)
Understand Business
Context
Identify Business
and Technical Risks
Synthesize and Rank
Risks
Define Risk
Mitigation Strategy
Carry Out Fixes
and Validate
Measurement and Reporting
Farkas
CSCE 824

12. What does it mean “weakest link” of defense?
Sample Questions
Give an example of vulnerability, threat, risk, and attack in the domain of …
What does it mean “weakest link” of defense?
Recommend a way to increase computing system’s security by incorporating security trade offs into the security planning.
Why do we need to understand the business context to have effective security?
Farkas
CSCE 824

13. Cryptography

14. Insecure communications
Sender
Snooper
Recipient
Insecure channel
Confidential

15. Cryptographic Protocols
Messages should be transmitted to destination
Only the recipient should see it
Only the recipient should get it
Proof of the sender’s identity
Message shouldn’t be corrupted in transit
Message should be sent/received once only

16. Conventional (Secret Key) Cryptosystem
Plaintext
Ciphertext
Plaintext
Encryption
Decryption
Sender
Recipient K
C=E(K,M)
M=D(K,C)
K needs
secure channel

17. Public Key Cryptosystem
Recipient’s public
Key (Kpub)
Recipient’s private
Key (Kpriv)
Plaintext
Ciphertext
Plaintext
Encryption
Decryption
Sender
Recipient
C=E(Kpub,M)
M=D(Kpriv,C)
Kpub needs
reliable channel

18. Cryptography Cryptanalyst’s goal: Taxonomy of attacks
Break message
Break key
Break algorithm
Taxonomy of attacks
Breakable vs. unbreakable cryptographic system
Properties of good cryptosystem.

19. Cryptosystem Vulnerabilities
Passive Attacker (Eavesdropper)
Active Attacker
Capabilities

20. Basic Encryption Techniques
Substitution
Permutation
Combinations and iterations of these
Techniques and attacks
ADVANTAGES/DISADVANTAGES!

21. Inherent Weaknesses of Symmetric Cryptography
Key distribution must be done secretly (difficult when parties are geographically distant, or don't know each other)
Need a key for each pair of users
n users need n*(n-1)/2 keys
If the secret key (and cryptosystem) is compromised, the adversary will be able to decrypt all traffic and produce fake messages

22. Product Ciphers
One encryption applied to the result of the other En(En-1(…(E1(M)))), e.g.,
Double transposition
Substitution followed by permutation, followed by substitution, followed by permutation…
Broken for
Chosen plaintext
Farkas
CSCE 824

23. Trustworthy Encryption Systems
Based on sound mathematics
Has been analyzed by experts
Has stood the test of time
Examples: Data Encryption Standard (DES), Advanced Encryption Standard (AES), River-Shamir-Adelman (RSA)

24. Public Key Encryption
Farkas
CSCE 824

25. Public-Key Encryption
Two keys – one is private one is public
Solves the key distribution problem (but need reliable channel)
Provides electronic signatures
Slower than secret-key encryption
Farkas
CSCE Farkas
CSCE 824 25

26. Public-Key Encryption
Needed for security:
One of the keys must be kept secret
Impossible (at least impractical) to decipher message if no other information is available
Knowledge of algorithm, one of the keys, and samples of ciphertext must be insufficient to determine the other key
Lecture 6
Farkas
CSCE 824
CSCE Farkas 26

27. RSA – Notation C = E(KE-B, M) M = D(KD-B,C) KE-B: public key of B
KD-B: private key of B
E: encryption alg.
D: decryption alg.
M: plaintext
C: ciphertext
Lecture 6
Farkas
CSCE 824
CSCE Farkas 27

28. RSA Med mod n = M mod n Both sender and receiver know n Sender knows e
Only receiver knows d
Modulus: Remainder after division, i.e., if a mod n=b then a=c*n+b
Need:
Find values e,d,n such that
Easy to calculate Me, Cd for all M < n
Infeasible to determine d give e
Med mod n = M mod n
Farkas
Lecture 6
CSCE Farkas
CSCE 824 28

29. Signature and EncryptionB A
Encrypted
Signed
Plaintext
Signed
Plaintext
Signed
Plaintext
Plaintext
Plaintext D E D E
B’s public key
A’s public key
B’s private key
A’s private key
Farkas
Lecture 6
CSCE 824
CSCE Farkas 29

30. Non-repudiation Requires notarized signature, involving a third party
Large system: hierarchies of notarization
Lecture 6
Farkas
CSCE 824
CSCE Farkas 30

31. Cryptographic Hash Functions
Farkas
CSCE 824

32. Hash Functions
Hash function h maps an input x of arbitrary length to a fixed length output h(x) (compression)
Accidental or intentional change to the data will change the hash value
Given h and x, h(x) is easy to compute (ease of computation)
Lecture 8-9
Farkas
CSCE 824
CSCE Farkas 32

33. Good Hash Function
It is easy to compute the hash value for any given message
It is infeasible to find a message that has a given hash
It is infeasible to modify a message without changing its hash
It is infeasible to find two different messages with the same hash
Lecture 8-9
Farkas
CSCE 824
CSCE Farkas 33

34. Cryptographic Protocols
Farkas
CSCE 824

35. Protocols Good protocol characteristics: Established in advance
Mutually subscribed
Unambiguous
Complete
Lecture 6
Farkas
CSCE 824
CSCE Farkas 35

36. Symmetric-Key without Server Symmetric-Key with Server
Symmetric-Key Distribution: Symmetric-Key Techniques
Symmetric-Key without Server
Symmetric-Key with Server
Lecture 6
Farkas
CSCE 824
CSCE Farkas 36

37. Symmetric-Key Distribution: Public-Key Techniques
Simple secret key distribution
Secret key distribution with confidentiality and authentication
Diffie-Hellman Key Exchange
Lecture 6
Farkas
CSCE 824
CSCE Farkas 37

38. Simple secret key distribution
Public key
of S
KE-S ||ID-S
2. E KE-S(Ksession)
Sender
Recipient
Secret
Session key
Vulnerable to active attack!
HOW?
Farkas
Lecture 6
CSCE Farkas
CSCE 824 38

39. With confidentiality and authentication
Assume: KE-R and KE-S are known in advance
Nonce
E KE-R[N1||ID-A]
2. E KE-S[N1||N2]
3. E KE-R[N2]
4. E KE-R E KD-S(Ksession)
Sender
Recipient
Question: Why do we need reliable distribution of public keys?
Farkas
Lecture 6
CSCE Farkas
CSCE 824 39

40. Intruder in the Middle Attack
John
Rose
Hi Rose, I’m John.
Hi Rose, I’m John.
Hi John, I’m Rose.
Hi John, I’m Rose.
Intruder and John
Uses Diffie-Hellman
To agree on key K.
Intruder and Rose
Uses Diffie-Hellman
To agree on key K’.
Question: the attacker may want to have K and K’ be the same, Why?
Farkas
Lecture 6
CSCE 824
CSCE Farkas 40

41. Asymmetric-Key Exchange
Without server
Broadcasting
Publicly available directory
With server
Public key distribution center
Certificates
Lecture 6
Farkas
CSCE 824
CSCE Farkas 41

42. Public-key certificates
Authority
KE-R
KE-S
C-S=EKD-CAuth[Time1,ID-S,KE-S]
CR=EKD-CAuth[Time2,ID-R,KE-R]
1. C-S
Sender
2. C-R
Recipient
Farkas
Lecture 6
CSCE Farkas
CSCE 824 42

43. Certificates Guarantees the validity of the information
Establishing trust
Public key and user identity are bound together, then signed by someone trusted
Need: digital signature
Lecture 6
Farkas
CSCE 824
CSCE Farkas 43

44. Digital Signature Need the same effect as a real signature
Un-forgeable
Authentic
Non-alterable
Not reusable
Lecture 6
Farkas
CSCE 824
CSCE Farkas 44

45. Digital signature
Direct digital signature: public-key cryptography based
Arbitrated digital signature:
Conventional encryption:
Arbiter sees message
Arbiter does not see message
Public-key based
Lecture 6
Farkas
CSCE 824
CSCE Farkas 45

46. Identification and Authentication
Farkas
CSCE 824

47. Authentication
Allows an entity (a user or a system) to prove its identity to another entity
Typically, the entity whose identity is verified reveals knowledge of some secret S to the verifier
Strong authentication: the entity reveals knowledge of S to the verifier without revealing S to the verifier

48. Authentication Information
Must be securely maintained by the
system.

49. Authentication Requirements
Network must ensure
Data exchange is established with addressed peer entity not with an entity that masquerades or replays previous messages
Network must ensure data source is the one claimed
Authentication generally follows identification
Establish validity of claimed identity
Provide protection against fraudulent transactions

50. User Authentication What the user knows What the user possesses
Password, personal information
What the user possesses
Physical key, ticket, passport, token, smart card
What the user is (biometrics)
Fingerprints, voiceprint, signature dynamics

51. Passwords Commonly used method
For each user, system stores (user name, F(password)), where F is some transformation (e.g., one-way hash) in a password file
F(password) is easy to compute
From F(password), password is difficult to compute
Password is not stored in the system
When user enters the password, system computes F(password); match provides proof of identity

52. Vulnerabilities of Passwords
Inherent vulnerabilities
Easy to guess or snoop
No control on sharing
Practical vulnerabilities
Visible if unencrypted in distributed and network environment
Susceptible for replay attacks if encrypted naively
Password advantage
Easy to modify compromised password.

53. Attacks on Password Guessing attack/dictionary attack
Social Engineering
Sniffing
Trojan login
Van Eck sniffing

54. Use the password exactly once!
One-time Password
Use the password exactly once!

55. Lamport’s scheme Doesn’t require any special hardware
System computes F(x),F2(x),…, F100(x) (this allows 100 logins before password change)
System stores user’s name and F100(x)
User supplies F99(x) the first time
If the login is correct, system replaces F100(x) with F99(x)
Next login: user supplies F98(x) … and so on
User calculates Fn(x) using a hand-held calculator, a workstation, or other devices

56. Time Synchronized Secret key Time DES One Time Password Farkas
CSCE 824

57. Challenge Response Non-repeating challenges from the host is used
The device requires a keypad
Network
Work
station
Host
User ID
Challenge
Response
Farkas
CSCE 824

58. Access Control
Farkas
CSCE 824

59. Access Control
Protection objects: system resources for which protection is desirable
Memory, file, directory, hardware resource, software resources, etc.
Subjects: active entities requesting accesses to resources
User, owner, program, etc.
Access mode: type of access
Read, write, execute

60. Access Control Requirement
Cannot be bypassed
Enforce least-privilege and need-to-know restrictions
Enforce organizational policy

61. Access Control
Access control: ensures that all direct accesses to object are authorized
Protects against accidental and malicious threats by regulating the reading, writing and execution of data and programs
Need:
Proper user identification and authentication
Information specifying the access rights is protected form modification
Farkas
CSCE 824

62. Access Control Access control components:
Access control policy: specifies the authorized accesses of a system
Access control mechanism: implements and enforces the policy
Separation of components allows to:
Define access requirements independently from implementation
Compare different policies
Implement mechanisms that can enforce a wide range of policies
Farkas
CSCE 824

63. Closed vs. Open Systems (minimum privilege) (maximum privilege)
Closed system
Open System
(minimum privilege)
(maximum privilege)
Access requ.
Access requ.
Allowed
accesses
Disallowed
accesses
Exists Rule?
Exists Rule?
yes no no
yes
Access
permitted
Access
denied
Access
permitted
Access
denied
Farkas
CSCE 824

64. Access Control Models All accesses Discretionary AC Mandatory AC
Role-Based AC
Farkas
CSCE 824

65. Discretionary Access Control
Access control is based on
User’s identity and
Access control rules
Most common administration: owner based
Users can protect what they own
Owner may grant access to others
Owner may define the type of access given to others

66. Access Matrix Model Read Write Own OBJECTS AND SUBJECTS File 1 File 2
Joe
Sam
Farkas
CSCE 824

67. Grant and Revoke GRANT <privilege> ON <relation>
To <user>
[WITH GRANT OPTION]
GRANT SELECT * ON Student TO Matthews
GRANT SELECT *, UPDATE(GRADE) ON Student TO FARKAS
GRANT SELECT(NAME) ON Student TO Brown
GRANT command applies to base relations as well as views

68. Grant and Revoke REVOKE <privileges> [ON <relation>]
FROM <user>
REVOKE SELECT* ON Student FROM Blue
REVOKE UPDATE ON Student FROM Black
REVOKE SELECT(NAME) ON Student FROM Brown

69. Non-cascading Revoke A B C D E F A revokes D’s privileges E B A F C
Farkas
CSCE 824

70. Cascading Revoke A B C D E F A revokes D’s privileges B A C Farkas
CSCE 824

71. Positive and Negative AuthorizationB C E D + -
Problem:
Contradictory authorizations
GRANT <privilege> ON X TO <user>
DENY <privilege> ON X TO <user>
Farkas
CSCE 824

72. Negative AuthorizationB C E D + - -
Positive authorization granted
By A to D becomes blocked but
NOT deleted.
Farkas
CSCE 824

73. DAC and Trojan Horse Brown: read, write Employee Read Employee
REJECTED!
Black is not allowed
To access Employee
Brown
Black, Brown: read, write
Black’s Employee
Black
Farkas
CSCE 824

74. DAC and Trojan Horse Brown: read, write Employee Word Processor Reads
Uses shared program
Brown
Black, Brown: read, write
Black’s Employee TH
Inserts Trojan Horse
Into shared program
Copies
Employee
To Black’s
Black
Farkas
CSCE 824

75. DAC Overview Advantages: Disadvantages: Intuitive Easy to implement
Inherent vulnerability (look TH example)
Maintenance of ACL or Capability lists
Maintenance of Grant/Revoke
Limited power of negative authorization

76. Mandatory Access Control
Objects: security classification
e.g., grades=(confidential, {student-info})
Subjects: security clearances
e.g., Joe=(confidential, {student-info})
Access rules: defined by comparing the security classification of the requested objects with the security clearance of the subject
e.g., subject can read object only if label(subject) dominates label(object)
Farkas
CSCE 824

77. Mandatory Access Control
If access control rules are satisfied, access is permitted
e.g., Joe wants to read grades.
label(Joe)=(confidential,{student-info})
label(grades)=(confidential,{student-info})
Joe is permitted to read grades
Granularity of access rights!
Farkas
CSCE 824

78. Mandatory Access Control
Security Classes (labels): (A,C)
A – total order authority level
C – set of categories
e.g., A = confidential > public , C = {student-info, dept-info}
(confidential,{student-info,dept-info})
(confidential,{student-info})
(confidential,{dept-info})
(confidential,{ })
(public,{student-info,dept-info})
(public,{student-info})
(public,{,dept-info})
(public,{ })
Farkas
CSCE 824

79. Mandatory Access Control
Dominance (): label l=(A,C) dominates l’=(A’,C’) iff A  A’ and C  C’
e.g., (confidential,{student-info})  (public,{student-info})
BUT
(confidential, {student-info})  (public,{student-info, department-info})
Farkas
CSCE 824

80. Bell- LaPadula (BLP) Model
Confidentiality protection
Lattice-based access control
Subjects
Objects
Security labels
Supports decentralized administration
Farkas
CSCE 824

81. BLP Reference Monitor
All accesses are controlled by the reference monitor
Cannot be bypassed
Access is allowed iff the resulting system state satisfies all security properties
Trusted subjects: subjects trusted not to compromise security
Farkas
CSCE 824

82. BLP Axioms 1.
Simple-security property: a subject s is allowed to read an object o only if the security label of s dominates the security label of o
No read up
Applies to all subjects
Farkas
CSCE 824

83. BLP Axioms 2.
*-property: a subject s is allowed to write an object o only if the security label of o dominates the security label of s
No write down
Applies to un-trusted subjects only
Farkas
CSCE 824

84. Blind Writes Improper modification of data
Most implementations disallow blind writes
Farkas
CSCE 824

85. Trojan Horse and BLP Secret Public Secret  Public Brown: read, write
Reference
Monitor
Employee
Word
Processor
Secret
Use shared program
Read
Employee
Brown
Black, Brown: read, write
Secret
Black’s Employee TH
Copy
Employee
To Black’s
Public
Insert Trojan Horse
Into shared program
Black
Secret  Public
Public
Farkas
CSCE 824

86. RBAC Motivation Multi-user systems Multi-application systems
Permissions are associated with roles
Role-permission assignments are persistent v.s. user-permission assignments
Intuitive: competency, authority and responsibility

87. CANNOT ENFORCE THESE PRINCIPLES
RBAC
Allows to express security requirements but
CANNOT ENFORCE THESE PRINCIPLES
e.g., RBAC can be configured to enforce BLP rules but its correctness depend on the configuration done by the system security officer.

88. Roles
User group: collection of user with possibly different permissions
Role: mediator between collection of users and collection of permissions
RBAC independent from DAC and MAC (they may coexist)
RBAC is policy neutral: configuration of RBAC determines the policy to be enforced

89. RBAC RBAC3 consolidated model RBAC1 RBAC2 role hierarchy constraints
RBAC0 base model
Farkas
CSCE 824

90. RBAC0 U Users User assignment Permission assignment R Roles P . . S
Permissions . . S
Sessions
Farkas
CSCE 824

91. RBAC1 Role Hierarchy . U Users R Roles P S Sessions User assignment
Permissions S
Sessions
User
assignment
Permission
Farkas
CSCE 824

92. RBAC1 Role Hierarchy Specialist Primary-care Physician Physician
Inheritance of
privileges
Physician
Health-care provider
Farkas
CSCE 824

93. RBAC2 U Users User assignment Permission assignment R Roles P
Permissions
Constraints . . S
Sessions
Farkas
CSCE 824

94. RBAC3 . U Users R Roles P S Sessions User assignment Permission
Permissions S
Sessions
User
assignment
Permission
Constraints
Farkas
CSCE 824

95. Next Class
Database security
Farkas
CSCE 824