C. Xu, 2002-2009 1 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu
Dec 25, 2015
C. Xu, 2002-2009 1
Security in Distributed SystemsII
ECE7610/ECE7995Cheng-Zhong Xu
C. Xu, 2002-2009 2
Outline• General Security Requirements
• Cryptography
• Secure Channel
• Access Control
• Security in Mobile Codes
• Case Studies– Kerberos Systems– SSL – SET
C. Xu, 2002-2009 3
Access Control• Client requests ops on resources that are controlled by server
Protection Approaches–Against invalid ops–Against unauthorized invocations–Against unauthorized users
C. Xu, 2002-2009 4
General Issues in Access Control• Subject makes a request to access an object• Access control is to protect object against invocations by unauthorized
subjects • Reference monitor records which subject may do what and decide
whether a subject is allowed to have a specific operation carried out on an object
• Reference monitor is called by local OS each time an object is invoked.
C. Xu, 2002-2009 5
Access Control Matrix and Variants
• Set of subject and Set of Objects– M[s,o] specifies which operations subject s can request
to be carried out on object o. Large sparse matrix
• Access Control List (ACL)– For each object, maintain a list of the access rights of
subjects that want to access the object
• Capabilities– A capability corresponds to an entry in the matrix– Each subject is given a list of capabilities (ticket) for
access to object. A ticket holder is given certain rights as associated with that ticket
C. Xu, 2002-2009 6
ACL versus Capabilities
• Using ACLs in (a), the server’s ref monitor will check if it knows the client and if the client is allowed to have the requested op carried out
• Using capabilities in (b) the ref monitor checks only if the capabilities is valid and if the requested op is listed in the capability.
C. Xu, 2002-2009 7
Access Control List in Unix• Abbreviation in ACL:
– Users of a file: owner, group owner, others– Rights: read (r), write (w), and execute (x)– Unix permissions are in three triplets
• Owner rights, group rights, other rights• E.g. rw-r- - - - -
• Abbreviations of ACL loss control flexibility– Hard to grant permission to specific user
• IBM’s AIX uses an ACL, called “extended permissions” to augment the traditional Unix abbrev of ACL (called “base permissions”). Eg. for a file xyz– Base permissions: rw-r- - - - -– Extended permissions: enabled | disabled
specify rw- u: jamespermit -w- u: alice, g=syspermit rw- u: bobdeny -w- u: james, g=students
Maintenance: conflict checking, update, revocation
C. Xu, 2002-2009 8
Capabilities in Java-based Systems• For web service security, a security policy file needs to
be specifiedjava –Djava.security.policy=java.policy SuperServer
• Code source based access control– Permissions may be per signer or per location
grant codeBase http://cic.eng.wayne.edu:*/, signedBy “Bob” { permission ServicePermission "yellow-page", "update, lookup";};
grant codeBase http://wayne.edu:*/ { permission ServicePermission "yellow-page", "lookup"; permission java.net.SocketPermission “*:1024-65535”, “connect, accept”;};
C. Xu, 2002-2009 9
Protection Domain
• A protection domain is an execution environment shared by a collection of processes; – It contains a set of (object, access rights) pairs, each of
which specifies legal ops for an object;
– operation requests are always issued within a domain.
• A PD is often associated with a given user. – When a user logs in, all her processes form a protection
domain.
• PD can also be organized in a hierarchical structure based on the concept of user groups
• In Java 1.2, the PD is determined by ClassLoader.
C. Xu, 2002-2009 10
Hierarchical Organization of PD• Example: Access control to web pages
– Instead of subject-oriented ACL, check if an employee belongs to a group– Maintaining group membership is easier, but membership lookup could be
costly at Reference Monitor
• A remedy is to let subject carry a membership certificate. When Dick wants to access a Web page, he hands over his certificate to the reference monitor. signed certificate
C. Xu, 2002-2009 11
Implementation of Capability
• Protection of capability integrity– Cryptographic checksum
• Copy and amplifying capabilities• Revocation of rights
– Revoking access to an object requires to revoke all capabilities granting access to the object too costly.
– How to solve this issue??
• Delegation??
C. Xu, 2002-2009 12
Role-based Access Control (RBAC)• Implementation of protection domain as roles• In RBAC, a user always logs into the system with
a specific role, associated with a function the user has in an organization– A user may have several functions: department head,
project manager, member of a committee. He can login as different role. His role determines the protection domain in which he will operate.
• Role change becomes independent of access control
C. Xu, 2002-2009 13
RBAC96 model(Currently foundation of a NIST/ANSI/ISO standard)
ROLES
USER-ROLEASSIGNMENT
PERMISSIONS-ROLEASSIGNMENT
USERS PERMISSIONS
... SESSIONS
ROLE HIERARCHIES
CONSTRAINTS
C. Xu, 2002-2009 14
Firewalls• Application-level gateway vs Packet-level Filtering• Gateway
– Cryptographic systems, plus access control, provide security services for parties that are subject to the same set of rules (protocols).
– Firewall, as a special kind of reference monitor, controls external access to any part of a distributed system.
C. Xu, 2002-2009 15
Packet Filtering
• internal network connected to Internet via router firewall
• router filters packet-by-packet, decision to forward/drop packet based on:– source IP address, destination IP address
– TCP/UDP source and destination port numbers
– ICMP message type
– TCP SYN and ACK bits
– state (think of NAT)
Should arriving packet be allowed
in? Departing packet let out?
C. Xu, 2002-2009 16
Outline• General Security Requirements
• Cryptography
• Secure Channel
• Access Control
• Security in Mobile Codes
• Case Studies– Kerberos Systems– SSL – SET
C. Xu, 2002-2009 17
Security in Mobile Codes
• Support mobile code for access to local resources in a flexible and fully controlled manner.
• Protect host from malicious codes
• Protect agent status from malicious hosts
C. Xu, 2002-2009 18
Protection of Agents• Impossible to fully protect agents from hosts. • An alternative is to detect any modifications by
the hosts (Ajanta).– Read-Only State: A collection of data items signed by
the agent’s owner (message digest plus encryption with its private key)
– Append-Only Logs: when a server S wants to append data X to the log, calculate checksum
Cinit = K+owner (Secret Nonce)
Cnew = K+owner (Cold, sig(S,X), S)
– Selective Public State: data items is encrypted with the designated server’s public key to ensure confidentiality
C. Xu, 2002-2009 19
Protection of Servers
• Java 1.0 Sandbox Organization (trusted or untrusted)
• Class loader: fetch classes and install in address space
• Byte code verifier: check if the classes contains illegal instr.
• Security Manager: perform security checks at run-time
C. Xu, 2002-2009 20
Java Security ArchitectureIn Java1.1, signed applets are introduced, based on digital signature
In Java 1.2: • All code, organized into domains, be subject to a security policy• Policy: a set of granted permissions
which specify rights to access particular resources
C. Xu, 2002-2009 21
Signed Code• Generate keys : (3) keytool –genkey –alias signedFiles –keypass kpi135 –
keystore susanstore –storepass ab987c
• (4) jarsigner –keystore susanstore –signedjar sCount.jar Count.jar signFiles
• (5) keytool –export –keystore susanstore –alias signFiles –file SusanJones.cer
On Receiving a Signed Code
1. Observe the Restricted App2. Import the Cer as a Trusted Cer3. Set up policies to grant Permission4. Run the applicaiton
C. Xu, 2002-2009 22
C. Xu, 2002-2009 23
Permission and Java Security Policy
• Java1.2 introduces typed access-control permissons: – Permission, FilePermission, SocketPermission, etc
• checkPermission() handles all security checks.SecurityManager sm = System.getSecurityManager();
sm.checkPermission( new AgentPermission(… …) );
• Security policy is a mapping from a set of properties that characterizes running code to a set of access permissions granted to the code– Java policies can be configured by the user or a system
administrator
– Default implementation in JDK uses an ASCII format
C. Xu, 2002-2009 24
Policy Enforcement I• Using Java object references as capability
– To access a local resource, the alien code must be given a reference to a specific object (resource proxy) that handles ops on the resource.
Is it possible for alien code to construct a reference to the proxyor even the proxy itself?
C. Xu, 2002-2009 25
Policy Enforcement II• Stack Introspection
– Any call to a method m of local resource is preceded by a special op enable_privilege that checks whether the caller is authorized to invoke m on that resource.
– This is the approach used in Web browser for dealing with Java applets
Stack introspection allowsfor the attachment of privilegesto classes or methods, and the checking of those privileges for each caller separately.
C. Xu, 2002-2009 26
Policy Enforcement III
• Name Space Management– The alien code provides the name of proxy (e.g.
FileHandler), which will be resolved to different classes at run-time depending on where the code came from.
Class pc = Class.forName( “FileHander” );ResourceHandler proxy = (ResourceHandler) pc.newInstance();
C. Xu, 2002-2009 27
Outline• General Security Requirements
• Cryptography
• Secure Channel
• Access Control
• Security in Mobile Codes
• Case Studies– Kerberos Systems– SSL – E-Cash and SET
C. Xu, 2002-2009 28
Case Study I: Kerberos System• Developed at MIT in 1980’s to assist clients in setting up a
secure channel with a server based on shared secret keys.– Kerberos server creates a shared secret key for any required server
and sends it (encrypted) to the user's computer– User's password is the initial secret shared with Kerberos
• Standardized and now included in most OSes– Internet RFC 1510, OSF DCE– BSD UNIX, Linux, Windows 2000, NT, XP, etc.
• Based on Needham-Schroeder authentication• Two components:
– Authentication Server (AS) for handling login requests. It authenticates a user and provides a key for setting up secure channels.
– Ticket Granting Service (TGS) handles the secure channel setting up. It hands out special messages, known as tickets, which are used to convince a server of the client identity.
C. Xu, 2002-2009 29
Basic IdeasStep B once per server session
Step C once per server transaction
Step A once per login session
ServerClient
DoOperation
Authenticationdatabase
Loginsession setup
Ticket-granting
service T
Kerberos Key Distribution Centre
Serversession setup
Authen-tication
service A
Servicefunction
3. Request forserver ticket
4. Server ticket
Step B
5. Service request
Request encrypted with session key
Reply encrypted with session key
Step C
1. Request forTGS ticket
2. TGSticket
Step A
TGS: Ticket-granting service
Ticket: a token issued by TGS for presentation to a particular server, verifying the sender has recently been authenticated.Session key: randomly generated by Kerberos and issued to a client for use when communicating with a particular server.
C. Xu, 2002-2009 30
Authentication in Kerberos• Alice logs on a distributed system based on Kerberos and
establishes a secure channel with server Bob.
KA,TGS and KA,B are session keysKAS,TGS(A, KA,TGS), KB,TGS(A, KA,B) are ticketsKA,AS is a secret key for password verification
Login and obtain a session key KA,B
Set up a secure channel
C. Xu, 2002-2009 31
Kerberos Protocol Details
• M1: Alice login• M2 [Alice name] to AS• M3 [Session key and ticket] to Alice• M4: promote password• M5: Type in password to generate session key Ka,as• M6: Request TGS to generate a session key for Bob, by
using its ticket. – Timestamp t is to prevent Chuck from malicious replaying M6
again and trying to setup a channel to Bob– TGS verifies the timestamp before returning a ticket to Alice. It if
differs more than a minutes from the current time, the request fro a ticket is rejected.
C. Xu, 2002-2009 32
Kerberized NFS (Network File Systems)
• Kerberos protocol is too costly to apply on each NFS operation
• Kerberos is used in the mount service:– to authenticate the user's identity– User's UserID and GroupID are stored at the server with the
client's IP address
• For each file request:– UserID and GroupID are sent encrypted in the shared session key– The UserID and GroupID must match those stored at the server – IP addresses must also match
• This approach has some problems– can't accommodate multiple users sharing the same client computer– all remote filestores must be mounted each time a user logs in
C. Xu, 2002-2009 33
Case Study II: Secure Socket Layer (SSL)
• Key distribution and secure channels for e-commerce– Hybrid protocol; depends on public-key cryptography– Originally developed by Netscape Corporation (1994)– Extended and adopted as an Internet standard with the name
Transport Level Security (TLS) in 1999– Provides the security in all web servers and browsers and in secure
versions of Telnet, FTP and other network applications
• Design requirements– Secure communication without prior negotation or help from 3rd
parties– Free choice of crypto algorithms by client and server– communication in each direction can be authenticated, encrypted
or both
C. Xu, 2002-2009 34
TLS Protocol Stack
SSLHandshake
protocol
SSL ChangeCipher Spec
SSL AlertProtocol
Transport layer (usually TCP)
Network layer (usually IP)
SSL Record Protocol
HTTP Telnet
SSL protocols: Other protocols:
negotiates cipher suite, exchanges certificates and key masters
changes thesecure channel to a new spec
implements the secure channel
C. Xu, 2002-2009 35
SSL Characteristics
• Client-initiated negotiations of encryption and authentication algorithms: SSL handshake protocol– Key exchange method (e.g. RSA or Diffie-Hellman)
– Cipher for data transfer (e.g. IDEA or DEA)
– Message digest function (e.g. SHA or MD-5)
• Bootstrapped secure session: SSL record protocol– Initial authentication: server passes a certificate containing
its public key signed by a Certificate Authority. If required, the client needs to send its certificate as well.
– Public-key cryptography to establish a secret session key
– Secure communication based on a shared session key
C. Xu, 2002-2009 36
SSL Handshaking Protocol
1. Hello messages (Unencrypted messages)– Client “Hello” - initiates session
• Propose protocol version
• Propose cipher suite
• Server chooses protocol and suite
– Client may request use of cached session• Server chooses whether to honor request
2. Certificate and Key Exchange messages
3. Change CipherSpec and Finished messages
C. Xu, 2002-2009 37
ClientA
ServerB
ClientHello
ServerHello
SSL handshake protocol
Establish protocol version, session ID, cipher suite, compression method, exchange random start values
Certificate
Certificate Request
ServerHelloDone
Optionally send server certificate and request client certificate
Certificate
Certificate VerifySend client certificate response if requested
Change Cipher Spec
Finished
Change Cipher Spec
Finished
Change cipher suite and finish handshake
*
Includes key master exchange.Key master is used by both A and Bto generate:2 session keys 2 MAC keys
KAB MAB
KBA MBA
C. Xu, 2002-2009 38
SSL handshake config. options
Component Description Example
Key exchangemethod
the method to be used forexchange of a session key
RSA with public-keycertificates
Cipher for datatransfer
the block or stream cipher to beused for data
IDEA
Message digestfunction
for creating messageauthentication codes (MACs)
SHA
*
C. Xu, 2002-2009 39
TLS: Key Exchange
• Server sends certificate containing public key (RSA) or Diffie-Hellman parameters– Certificate, issued by Certificate Authority (CA), binds
the public-key with identify
– Must recognize the CA in received certificate (in chain)• Examples of Certificate Authorities: Verisign and Thawte
• Client sends encrypted “pre-master” secret to server, encrypted with the public key– Pre-master secret is a large random number used for
both server and client to generate two session keys for encrypting data in each direction.
C. Xu, 2002-2009 40
X.509: Certificate Content and Validation
• Version
• Serial Number
• Signature Alg. Identifier– Object Identifier (OID)
– e.g. id-dsa: {iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 1}
• Issuer (CA) X.500 name
• Validity Period
• Subject X.500 name
• Subject Public Key– Algorithm
– Value
• Issuer Unique Id (Ver 2 ,3)
• Subject Unique Id (Ver. 2,3)
• Extensions (version 3)– optional
• CA digital signature
CA digital signature, encrypted with RSAcontains a hash of signature for verification, after decryption
C. Xu, 2002-2009 41
TLS: Record Protocol
Application data abcdefghi
abc def ghiRecord protocol units
Compressed units
MAC
Encrypted
TCP packet
Fragment/combine
Compress
Hash
Encrypt
Transmit
MAC: Message Authentication CodeMAC = Digest (message, secret)
C. Xu, 2002-2009 42
Case Study III: SET
• Traditional Organizations for Payment
a. In cashb. Using checkc. Using credit cards
C. Xu, 2002-2009 43
Other Payment Options
• Payment by money wiring• Payment through debit order
C. Xu, 2002-2009 44
Electronic Payment and Security• Types of digital money
– Smart card capable of withdrawing from bank account using your home PC.
– Digital coins, stored locally on HD
• General Security Requirements– Protection against fraud– Protection from being used more than once– Easy authentication– Protection against repudiation– Privacy: anonymous payment
• Make customer anonymous; not necessary for merchant• Conditional anonymous: identifiable, if needed.
C. Xu, 2002-2009 48
Secure Electronic Transaction (SET)
• Open standard developed by joint efforts of Visa and MasterCard.
• Alice purchases goods from Bob using a credit card– She sends order information, along with her Credit
Card number to Bob;– Bob’s bank will complete the payment, without the
knowledge of order information.– Bob shouldn’t know every detail about the payment
either.
C. Xu, 2002-2009 49
Dual Signature
• Let m1 and m2 denote the order and payment information
• Construct msg digest md1, md2, and a third msg digest mddual = H( concat(md1, md2) )
• Alice signed mddual and sends the following to Bob: – m1, md2, mddual, K-
A (mddual), denoted as [m1 | m2 ]A – This enables Bob to authenticate Alice and verify that she
has placed a signature on the entire message. – However, Bob can’t read m2.
C. Xu, 2002-2009 50
Skeleton of SET Protocol
• After clearance on the payment, the bank returns (in msg 3) a signed authorized msg auth_ok, encrypted by a newly generated session key.
• The response also contains a capture msg, which is used by Bob to claim the payment from the bank. The capture msg is uniquely associated with the entire transaction via a transaction identifier
• Authentication is performed at each step by sending certificates of public keys.
[m1|m2]A denotes a dual signature on msg m1 and m2, where only m1 is disclosed.
Request Authorization
C. Xu, 2002-2009 51
Summary• Secure Channels
– Authentication: DES, Kerbero system
– Message Integrity: Digital signature
– Confidentiality: Session key
• Access Control – Authorization: ACL and Certificate
– Access Control in Mobile Code
• Case Studies:– Java Security Architecture
– Kerberos
– SSL
– SET on-line payment
• Security in Naplet System ?
C. Xu, 2002-2009 52
Backup
C. Xu, 2002-2009 53
• Security policies in Java– A set of permissions granted to a subject or code.– Security policy based on Subject
• New permission types in Naplet system– NapletRuntimePermission(target)– NapletServicePermission(service, actions)– NapletSocketPermission(server, actions)
Access Permissions in Naplet
grant codeBase “http://cic.eng.wayne.edu:*/”, signedBy “Bob” , Principal NapletPrincipal “czxu\wayne.edu/QueryNaplet” { permission ServicePermission "yellow-page", "lookup";};
grant codeBase “http://cic.eng.wayne.edu:*/”, signedBy “Bob” , Principal NapletPrincipal “czxu\wayne.edu/HelloNaplet” { permission java.net.SocketPermission “*:1024-65535”, “connect, accept”;};
C. Xu, 2002-2009 54
Access Permissions in Naplet
• NapletRuntimePermission(target)– target includes “land”, “clone”, “execute”, “suspend”, “shutdown’.
– E.g.
• NapletServicePermission(service, actions)– Permission for naplet or administrator to access the target service
– E.g.
1
grant Principal NapletAdministrator “administrator”{ permission NapletRuntimePermission(“shutdown”);}grant Principal NapletPrincipal “czxu\wayne.edu/HelloNaplet.*” { permission NapletRuntimePermission(“land”);}
grant Principal ServerAdministrator “administrator” { permission NapletServicePermission( “yellow-page”, “lookup, update”);}grant Principal NapletPrincipal “czxu\wayne.edu/QueryNaplet” { permission NapletServicePermission(“yellow-page”, “lookup”);}
C. Xu, 2002-2009 55
Access Permissions in Naplet
• NapletSocketPermission(server, actions)– Permission for naplet communication and migration
– E.g.
• Permission implication– 1
– Implement boolean implies(Permission perm)
– Implication based on name resolution of NapletPrincipal
)()(, sPermissionqsPermissionpqp
grant Principal NapletPrincipal “czxu\wayne.edu/HelloNaplet” { permission NapletSocketPermission( “ece.wayne.edu:2400/YellowPage”, “talk, travel”);}
C. Xu, 2002-2009 56
• Positive vs. negative permissions• An example in subject-oriented access control
– “To allow any hello naplets from wayne.edu to land, except those from xyz\wayne.edu”
– Customized permission check for access denials
111111
Customized Permission Check
grant Principal NapletPrincipal “\wayne.edu/HelloNaplet” { permission NapletRuntimePermission(“land”);}
public class NapletSecurityManager extends SecurityManager { public void checkPermission( Permission perm) { if (perm instanceof NapletRuntimePermission) { Subject sbj = Subject.getSubject(AccessController.getContext()); String name = perm.getName(); if ( sbj.getPrincipals() contains “xyz\wayne.edu /HelloNaplet” and name is “land” ) throw new SecurityException(“HelloNaplet from xyz is denied”); else super.checkPermission( perm );} } }