EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

30
EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim

Transcript of EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Page 1: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

EE515/IS523 Think Like an AdversaryLecture 5

Access Control in a Nutshell

Yongdae Kim

Page 2: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Recap http://security101.kr

E-mail policy Include [ee515] or [is523] in the subject of your e-mail

Student Survey http://bit.ly/SiK9M3

Student Presentation Send me email.

Preproposal deadline: This Wednesday 9:00 AM

Page 3: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Challenge-response authentication

Alice is identified by a secret she possessesBob needs to know that Alice does indeed possess this secret

Alice provides response to a time-variant challenge

Response depends on both secret and challenge

UsingSymmetric encryptionOne way functions

Page 4: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Challenge Response using SKE

Alice and Bob share a key KTaxonomy

Unidirectional authentication using timestampsUnidirectional authentication using random numbers

Mutual authentication using random numbers

Unilateral authentication using timestampsAlice Bob: EK(tA, B)Bob decrypts and verified that timestamp is OKParameter B prevents replay of same message in B A direction

Page 5: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Challenge Response using SKEUnilateral authentication using random numbersBob Alice: rb

Alice Bob: EK(rb, B)

Bob checks to see if rb is the one it sent out Also checks “B” - prevents reflection attack

rb must be non-repeating

Mutual authentication using random numbersBob Alice: rb

Alice Bob: EK(ra, rb, B)

Bob Alice: EK(ra, rb)

Alice checks that ra, rb are the ones used earlier

Page 6: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Challenge-response using OWF

Instead of encryption, used keyed MAC hK

Check: compute MAC from known quantities, and check with message

SKID3Bob Alice: rb

Alice Bob: ra, hK(ra, rb, B)

Bob Alice: hK(ra, rb, A)

Page 7: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Key Establishment, Management

Key establishmentProcess to whereby a shared secret key becomes available to two or more parties

Subdivided into key agreement and key transport.

Key managementThe set of processes and mechanisms which support key establishment

The maintenance of ongoing keying relationships between parties

Page 8: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Access Control in a Nutshell

Yongdae Kim

Page 9: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Kerberos vs. PKI vs. IBE

Still debating Let’s see one by one!

Page 10: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Kerberos (cnt.)

T

A B

A, B, NA

EEKBT

KBT(k, A, L), E

(k, A, L), E K

AT

KAT(k, N

(k, N AA, L, B)

, L, B)

EEKBTKBT(k, A, L), E(k, A, L), Ekk(A, T(A, TAA, A, Asubkeysubkey))

EEkk(T(TAA, B, Bsubkeysubkey))

•EEKBTKBT(k, A, L): Token for B(k, A, L): Token for B•EEKATKAT(k, N(k, NAA, L, B): Token for A, L, B): Token for A•L: Life-timeL: Life-time•NNAA??

•EEkk(A, T(A, TAA, A, Asubkeysubkey): To prove B that A knows k): To prove B that A knows k•TTAA: Time-stamp: Time-stamp

•EEkk(B, T(B, TAA, B, Bsubkeysubkey): To prove A that B knows k): To prove A that B knows k

Page 11: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Kerberos (Scalable)

T (AS)

A B

A, G, NA

EEKGT

KGT(k(k A

GAG, A, L), E

, A, L), E K

AT

KAT(k(k A

GAG, N

, N AA, L, G)

, L, G)

EEKGB KGB (k(kABAB, A, L, N, A, L, NAA’’), E), EkABkAB(A, T(A, TAA’’, A, Asubkeysubkey))

EEkk(T(TAA’’, B, Bsubkeysubkey))

G (TGS)

EE KGT

KGT(k(k AGAG

, A, L), E

, A, L), E kA

GkAG(A,

(A,

TT AA), B, N

), B, N AA

’’

EE KAG

KAG(k(k ABAB

, N

, N AA’’, L, B), E

, L, B), E kG

BkGB(k(k ABAB

, A, L, N

, A, L, N AA’’), B, NA

), B, NA

’’

Page 12: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Public Key Certificate Public-key certificates are a vehicle

public keys may be stored, distributed or forwarded over unsecured media

The objective make one entity’s public key available to others such that its authenticity and validity are verifiable.

A public-key certificate is a data structure data part

cleartext data including a public key and a string identifying the party (subject entity) to be associated therewith.

signature part digital signature of a certification authority over the data part

binding the subject entity’s identity to the specified public key.

Page 13: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

CA

a trusted third party whose signature on the certificate vouches for the authenticity of the public key bound to the subject entityThe significance of this binding must be provided by additional means, such as an attribute certificate or policy statement.

the subject entity must be a unique name within the system (distinguished name)

The CA requires its own signature key pair, the authentic public key.

Can be off-line!

Page 14: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

ID-based CryptographyNo public keyPublic key = ID (email, name, etc.)PKG

Private key generation centerSKID = PKGS(ID)PKG’s public key is public.distributes private key associated with the ID

Encryption: C= EID(M)

Decryption: DSK(C) = M

Page 15: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Discussion (PKI vs. Kerberos vs. IBE)

On-line vs. off-line TTPImplication?

Non-reputation?Revocation?Scalability?Trust issue?

Page 16: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

OS SecurityOS Security is essentially concerned with four problems:User authentication links users to processes.

Access control is about deciding whether a process can access a resource.

Protection is the task of enforcing these decisions: ensuring a process does not access resources improperly.

Isolation is the separation of processes’ resources from other processes.

Page 17: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Access ControlThe OS mediates access requests between subjects and objects.

This mediation should (ideally) be impossible to avoid or circumvent.

? ObjectSubject

Referencemonitor

Page 18: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Definitions Subjects make access requests on objects.

Subjects are the ones doing things in the system, like users, processes, and programs.

Objects are system resources, like memory, data structures, instructions, code, programs, files, sockets, devices, etc…

The type of access determines what to do to the object, for example execute, read, write, allocate, insert, append, list, lock, administer, delete, or transfer

Page 19: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Access Control Discretionary Access Control:

Access to objects (files, directories, devices, etc.) is permitted based on user identity

Each object is owned by a user. Owners can specify freely (at their discretion) how they want to

share their objects with other users, by specifying which other users can have which form of access to their

objects. Discretionary access control is implemented on any multi-user OS

(Unix, Windows NT, etc.). Mandatory Access Control:

Access to objects is controlled by a system-wide policy for example to prevent certain flows of information.

In some forms, the system maintains security labels for both objects and subjects

based on which access is granted or denied.

Labels can change as the result of an access Security policies are enforced without the cooperation of users or

application programs. Mandatory access control for Linux:

http://www.nsa.gov/research/selinux/

Page 20: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Access Control MatrixObj 1 Obj 2 Obj 3 … Obj n

Subj 1 rwl rwlx - - l

Subj 2 rwl rlx rwl - -

Subj 3 - - - rl r

Subj m rl lw rl rw r

Page 21: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

RepresentationsAn access control matrix canbe represented internally indifferent ways:

Access Control Lists (ACLs)store the columns with theobjects

Capability lists store the rows with the subjects

Role-based systems group rights according to the “role” of a subject.

O1 O2 …

S1 rwl wl -

S2 ida wlk -

S3 - - rl

Sm rwlx wi w

Page 22: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Access Control ListsThe ACL for an object lists the access rights of each subject (usually users).

To check a request, look in the object’s ACL.

ACLs are used by most OSes and network file systems, e.g. NT, Unix, and AFS.

Page 23: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

ACL ProblemsTo be secure, the OS must authenticate that the user is who (s)he claims to be.

To revoke a user’s access, we must check every object in the system.

There is often no good way to restrict a process to a subset of the user’s rights.

Page 24: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

CapabilitiesCapabilities store the allowed list of object accesses with each subject.

When the subject requests access to object O, it must provide a “ticket” granting access to O.

These tickets are stored in an OS-protected table associated to each process.

No widely-used OS uses pure capabilities. Some systems have “capability-like” features: e.g. Kerberos, NT, OLPC, Android

Page 25: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

ACL vs. CapabilitiesCapabilities do not require authentication: the OS just checks each ticket on access requests.

Capabilities can be passed, or delegated, from one process to another.

We can limit the privileges of a process, by removing unnecessary tickets from the table.

Page 26: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Roles

S1 S2 S3 Sm

O1 O2 On…

… S1 S2 S3 Sm

O1 O2 On…

R1 R2

Page 27: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Unix/POSIX Access Controlkyd@dio (~) % iduid=3259(kyd) gid=717(faculty)

groups=717(faculty),1686(mess),1847(S07C8271),1910(F07C5471),2038(S08C8271)

kyd@dio (~) % ls -l News_and_Recent_Events.zip -rw-rw-rw- 1 kyd faculty 714904 Feb 22 10:00

News_and_Recent_Events.zip

kyd@dio (/web/classes02/Spring-2011/csci5471) % ls –aldrwxrwsr-x 4 kyd S11C5471 512 Jan 19 10:23 ./drwxr-xr-x 46 root daemon 1024 Feb 17 23:04 ../drwxrwsr-x 3 kyd S11C5471 512 Feb 16 00:36 Assignment/

Page 28: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Mandatory Access Control policies

Restrictions to allowed information flows are not decided at the user’s discretion (as with Unix chmod), but instead enforced by system policies.

Mandatory access control mechanisms are aimed in particular at preventing policy violations by untrusted application software, which typically have at least the same access privileges as the invoking user.

Page 29: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

Data Pump/Data DiodeLike “air gap” security, but with one-way communication link that allow users to transfer data from the low-confidentiality to the high- confidentiality environment, but not vice versa.

Examples:Workstations with highly confidential material are configured to have read-only access to low confidentiality file servers.

Page 30: EE515/IS523 Think Like an Adversary Lecture 5 Access Control in a Nutshell Yongdae Kim.

The covert channel problem

Reference monitors see only intentional communications channels, such as files, sockets, memory.

However, there are many more “covert channels”, which were neither designed nor intended to transfer information at all.

A malicious high-level program can use these to transmit high-level data to a low-level receiving process, who can then leak it to the outside world.

Examples for covert channels: Resource conflicts – If high-level process has already created a file F, a

low-level process will fail when trying to create a file of same name → 1 bit information.

Timing channels – Processes can use system clock to monitor their own progress and infer the current load, into which other processes can modulate information.

Resource state – High-level processes can leave shared resources (disk head position, cache memory content, etc.) in states that influence the service response times for the next process.

Hidden information in downgraded documents – Steganographic embedding techniques can be used to get confidential information past a human downgrader (least-significant bits in digital photos, variations of punctuation/spelling/whitespace in plaintext, etc.).