SDSI - S imple Distributed Security Infrastructure

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

Outline

1. Introduction

2. Motivation

3. Context

4. SDSI Terminology

5. Overview

6. Applications

7. Recap & Summary

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.

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.

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

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.

4. SDSI Terminologya. Keys & Principalsb. Data Structure & S-expressionc. Signatured. Certificatee. Namesf. Groupsg. Compressionh. Object & Message Typei. Protocolsj. Access Control List (ACL)

5. Overviewa. 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 key is so unique that writing the hash is as good as writing the whole public key.

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.

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…)))

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.

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.

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.

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.

d. Certificates   A certificate is a digitally signed message from a

CA 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

Sample Certificate

(certificate

(issuer (ref <my-key> “Bob Smith”))

(subject <bob’s-key>)

(not-after 1996-03-19_07:00 )

(tag (*)))

Certificate chainsA 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))

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.

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.

e. Names in SDSIPublic 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“.

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“.

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.

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”

may refer to the same principal. 

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.

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.

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.

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.

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 )

……) 

Standard SDSI Object Types 1. Cryptographic Keys

a.  public keys are for signature verification &/or encryption

b. private keys are for signing &/or decryptionc. shared secret key is used for encryption,

decryption, or for computing MAC (message authentication codes).

2. Principals : (above) 

3. Encrypted ObjectsThe 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.

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. 

4. Signed ObjectsSigning 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

The objects can be “co-signed” with

- parallel co-signatures:

result of two or more signers independently signing an object

-cascaded co-signatures:

appending their independent signatures to the end of object, which means these are

cumulative.

i. 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.

j. ACLThe 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: .. .. ))

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.

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‘.

4. Distributing signed codeCode 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.    

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: .. .. .. .. .. ))

(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.

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 and

authorization patterns. Simple syntax

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.