SDSI - S imple Distributed Security Infrastructure

1. SDSI - Simple Distributed Security Infrastructure Original paper by Ronald L. Rivest, MIT Butler Lampson, Microsoft Corporation April 30, 1996 Presentation for IT- 525 at IU by RajeshCJoshi MICT-Winter2001 April 10, 2001

2. Outline • Introduction • Motivation • Context • SDSI Terminology • Overview • Applications • Recap & Summary

3. 1. Introduction • SDSI ( Simple Distributed Security Infrastructure) is a specification for a simple public key infrastructure. • SDSI takes public-key cryptography and introduces a format for making simple statements called certificates for providing security in distributed systems. • A similar effort is the SPKI (Simple Public Key Infrastructure) by Carl Ellison and others to design public-key infrastructure for IETF.

4. SDSI has been developed by Professors Ronald L. Rivest and Butler Lampson of MIT's Laboratory for Computer Science, members of LCS's Cryptography and Information Security research group. • SDSI research is supported by DARPA‘s "Security for Distributed Computer Systems". • According to Rivest and Lampson, SDSI is a simple yet powerful framework for managing security in a distributed environment.

5. 2. Motivations •  Incredibly slow development of PK infrastructure • Sense that existing PK infrastructure proposals are: –too complex –inadequate for secure distributed systems • A need within W3C security working group for a better PK infrastructure

6. 3. Context • SDSI is based on public-key cryptography where everyone has a matched public key and private key for scrambling messages. • Once a signature is made on a message, anyone that knows the public key can verify that signature by unscrambling it and comparing that to the message. • As the public key can correctly unscramble signatures that were made by its matched private key, a correct signature (and therefore, the message) can be believed to be authentic.

7. 4. SDSI Terminology a. Keys & Principals b. Data Structure & S-expression c. Signature d. Certificate e. Names f. Groups g. Compression h. Object & Message Type i. Protocols j. Access Control List (ACL)

8. 5. Overview • Keys & Principals Keys can be indicated by: – its hash value – its encrypted form – its name  Public keys are so long that it's nice to use shorthand for them. The "hash" of public keyis so unique that writing the hash is as good as writing the whole public key.

9. Principals are public keys: SDSI principals are public digital signature verification keys. Each Principal is a certification authority: In SDSI, certificates can be created and signed by anyone : i.e. anyone can be a “CA” and policies depend on the discretion of the principal.

10. A principal is identified with the corresponding verification (public) key and are represented by a data structure that can be passed around, such as: (public-key (rsa-md5-verify object signature (const &03)(const &435affd1…)))

11. All keys are equal: Each principal can make signed statements and requests on the same basis as any other principal. Apart from the egalitarian design (i.e. without hierarchy), SDSI also allows some principals to have special status as “distinguished roots” – but for convenience rather than necessity.

12. b. Data Structure & S-expression SDSI uses S-expressions where S-expressions are a data structure for representing complex data. They have a clean human-readable ASCII representation. And, the concept of “presentation hint” enables octet-strings to be represented in italics, or as Unicode characters, or even as photos, etc. e.g. [image/gif] as presentation hint.

13. Each S-expressions has ASCII “external” representations for transmission or storage. • SDSI representation uses alphanumeric characters, special characters, white spaces, etc. • Indentation is not significant, and parentheses are used for grouping. • The hash value H(S) of an S-expression (S) is obtained by applying a cryptographic hash algorithm, such as MD5 or SHA-1 to S’s canonical ASCII expression. • SDSI’s default hash algorithm is SHA-1.

14. c. Flexible Signatures: SDSI signatures may be appended to the objects being signed, or they may be detached from the signed objects. Objects may be co-signed by several signers. Signatures may contain collections of relevant certificates. Signatures may have expiration dates, and/or may require periodic re-confirmation.

15. d. Certificates A certificate is a digitally signed message from aCA that binds a public key to a name. These can be passed around, or managed in directories.  Uses of Certificates: –binding a local name to a value –defining membership in a group –delegating rights to others –specifying attributes of documents and of key-holders

16. Sample Certificate (certificate (issuer (ref <my-key> “Bob Smith”)) (subject <bob’s-key>) (not-after 1996-03-19_07:00 ) (tag (*)))

17. Certificate chains A sequence of certificates can form a chain, where definitions cascade and rights flow. {K1} ==> {K1 mit rivest} (tag (read foo)){K1 mit} ==> {K2}(tag (read (*))){K2 rivest}=> {K3} (tag (read (*)))is equivalent to:{K1} ==> {K3} (tag (read foo))

18. Propagation Control If a certificate turns on propagation control then rewriting of issuer’s name in a certificate chain can not proceed any further than the point where it is rewritten to be a single key. Authorization (or, Delegation) Certificates A delegation certificate authorizes a group (of servers) the authority to sign on behalf of the signing principal.

19. Auto-Certs It is a special kind of certificate – having been signed by the principal himself, having the object type Auto-Cert, and involving no third party vouching for it. Each principal must have an auto-certificate, which may give additional information not given in the Principal: object. The Principal: object specifies one or more auto-cert servers that can respond to a query with the auto-cert.

20. e. Names in SDSI Public keys are long numbers, and people have a hard time remembering numbers. SDSI's answer to this problem is that there is no „big phone book“. With everyone keeping their own little phone books of the people they know, and telling people who they know when they are asked, one can find just about anyone, just like a game of "six degrees of separation“.

21. Why names are local in SDSI? - Global name spaces are politically and technically difficult to implement. - Standards of global nature must be created for issuing certificates. - So, there is no global name space, but each principal has its own local name space. These names may be derived from nicknames, email addresses, account numbers, etc. –“Linking of Name Spaces“.

22. Standard Roots and Global Name Spaces To allocate some universally recognized “distinguished root” principals, SDSI has reserved names ending with double exclamation marks(!!). e.g. VeriSign!!’s Microsoft’s Susan-Smith DNS!!’s edu’s mit’s lcs’s rivest, etc.

23. Multiple Global Names A principal will have multiple global names if there are multiple paths from distinguished roots to that principal. e.g. VeriSign!!’s Microsoft’s CEO DNS!!’s com’s microsoft’s “Bill Gates” mayrefer to the same principal. 

24. DNS names have a special status: SDSI includes custom treatment for DNS(Internet email) names, so that Bob.Smith@penguin.microsoft.com is equivalent to DNS!!’s com’s microsoft’s penguin’s Bob.Smith.

25. f. Groups   A principal may define a local name to refer to a group of principals: e.g.“friends“ include bob alice tom A group does not have an associated public key. No principal is authorized to speak for the group, although the owner of the group can change its definition.

26. g. Compression SDSI has a fairly expansive, human-readable syntax. So, for greater economy in transmission, SDSI has a simple “macro” capability. For example, if a special token begins with a star, then it is looked up in a fixed published standard table for substitution. e.g. *c => Cert;*P => Principal; etc.

27. Star macros: All common SDSI tokens have such a “short form”. Star macros are only used for transmission. They are used to compress a message before transmission, and to decompress upon receipt. They are not used for storage, and never present when a hash computation is performed.

28. h. Object types Lists are used to represent most SDSI objects. The first element of the list gives the type of the object, and the rest is a sequence of attribute/value pairs. e.g. (type: (Attribute1: value1) (Attribute2: value2a value2b value2c ) ……) 

29. Standard SDSI Object Types 1. Cryptographic Keys a.  public keys are for signatureverification&/or encryption b. private keys are for signing &/or decryption c. shared secret key is used forencryption, decryption, or for computing MAC(messageauthentication codes).

30. 2. Principals : (above) 3. Encrypted Objects The encryption of an object X is an object whose attribute/value fields indicate the encryption key (either a public key or a shared-secret key) used to encrypt the object and give the ciphertext an ASCII representation of X. The ciphertext may be an arbitrary sequence of S-expressions.

31. The object type may either be a.)Encrypted-Macro temporary envelope that should be immediately decrypted by the recepient, and replaced by the decrypted contents. b.) Encrypted objects that should only be decrypted “as necessary” during other processing.

32. 4. Signed Objects Signing creates a separate object, containing the hash of object being signed. Object can be signed in either a.)wrapped-mode(object,hash) signed object contains the object being signed or its hash b.)appendix-mode (signature) signature is appended to the end of signed object

33. The objects can be “co-signed” with - parallel co-signatures: result of two or more signers independently signing an object -cascaded co-signatures: appending theirindependent signatures to the end of object,which means these are cumulative.

34. Protocols Communication is SDSI takes place as a sequence of protocols between two parties – typically, one party is called the “client or requestor” and the other is called “server”. A typical protocol might be a query/response protocol, but the authors of the article mention that a SDSI design goal is to provide a convenient framework for incorporating other protocols.

35. j. ACL The design of SDSI intends to make sure that ACL‘s can be written in a clear and easily auditable manner, using names for principals or groups. e.g. the certificate for group-23 can only be read by its members, like: (Cert: (Local-Name: group-23) (Value: (Group: friends colleagues)) (ACL: (read: group-23)) (Signed: .. .. ))

36. 6. Applications Possible Application Scenarios 1.    Mail Reader When a mail reader receives a SDSI-signed object, it can display to the user a local nick-name for the signer, if one exists in the local data-base. In case, there is no local name for the signer in the local database, then one of the signer’s global names might be displayed after checking the appropriate credentials included by the signer for verification.

37. 2. Access Control for web pages server maintains an access-control list (ACL) for each managed object (e.g. web page) 3.Kerberos-like ticket A short-lived certificate stating that x is a member of a group ‚g‘ can be used as a Kerberos-like ticket. It denotes authorization to use some resources that has an ACL containing ‚g‘.

38. 4. Distributing signed code Code can be signed using the two-part detached wrapped-hash form. This means the executable code itself is not modified in any way. 5. Corporate database access Each record in the corporate database can be tagged with the name of the group of principals allowed to access it.    

39. 6. Multi-cast Broadcasting a confidential message can be done as follows, for example by posting the message to the iumict-it525 Usenet news-group: (Encrypted: (Key: (ref: server’s iumict-study-crypto )) (Ciphertext: .. .. .. .. .. ))

40. (Cert: (Local-Name: iumict-study-crypto) (Value: (Shared-Secret-Key: (Algorithm: RC5… … …))) (ACL: (read: iumict-it525)) (Signed: .. .. .. )) This allows the members of the group to obtain the RC5 decryption key, and thus read the posted multi-cast announcement.

41. 7. Recap & Summary Major design principles: • ACLs must be easy to write & understand • Principals are public keys • Linked local name spaces • Groups provide clarity for ACLs • On-line client/server orientation • Client does work of proving authorization • Certificates support flexible naming andauthorization patterns. • Simple syntax

42. Certificates can be name certificates, which attach names to the public keys of other people, or delegation certificates, which give others permission to do some of the things that they are allowed to do. With the ability to have names and give permission, SDSI hopes to bring a real sense of security to the Internet, by having a clear way of saying who can do what on the network.