Top Banner
C. Xu, 2002-2009 1 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu
53

C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

Dec 25, 2015

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

C. Xu, 2002-2009 1

Security in Distributed SystemsII

ECE7610/ECE7995Cheng-Zhong Xu

Page 2: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-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

Page 3: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 4: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 5: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 6: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 7: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 8: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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”;};

Page 9: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 10: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 11: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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??

Page 12: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 13: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 14: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 15: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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?

Page 16: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

C. Xu, 2002-2009 16

Outline• General Security Requirements

• Cryptography

• Secure Channel

• Access Control

• Security in Mobile Codes

• Case Studies– Kerberos Systems– SSL – SET

Page 17: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 18: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 19: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 20: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 21: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 22: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 23: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 24: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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?

Page 25: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 26: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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();

Page 27: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 28: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 29: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 30: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 31: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 32: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 33: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 34: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 35: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 36: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 37: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 38: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

*

Page 39: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 40: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 41: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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)

Page 42: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

C. Xu, 2002-2009 42

Case Study III: SET

• Traditional Organizations for Payment

a. In cashb. Using checkc. Using credit cards

Page 43: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

C. Xu, 2002-2009 43

Other Payment Options

• Payment by money wiring• Payment through debit order

Page 44: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 45: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 46: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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.

Page 47: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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

Page 48: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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 ?

Page 49: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

C. Xu, 2002-2009 52

Backup

Page 50: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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”;};

Page 51: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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”);}

Page 52: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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”);}

Page 53: C. Xu, 2002-20091 Security in Distributed Systems II ECE7610/ECE7995 Cheng-Zhong Xu.

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 );} } }