security management key management in the case of public-key cryptosystems, we assumed that a sender...

20
SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at its disposal so that it could encrypt the message to ensure confidentiality. Likewise, in the case of authentication using a key distribution center (KDC), we assumed each party already shared a secret key with the KDC

Upload: teresa-daniel

Post on 01-Jan-2016

214 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems,

we assumed that a sender of a message had the public key of the receiver at its disposal so that it could encrypt the message to ensure confidentiality.

Likewise, in the case of authentication using a key distribution center (KDC), we assumed each party already shared a secret key with the KDC

Page 2: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Key Establishment

Page 3: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Diffie- Hellman key exchange

Page 4: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Key Distribution

Page 5: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at
Page 6: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Authenticated distribution of public keys public-key distribution takes place by means of

public-key certificates. Such a certificate consists of a public key

together with a string identifying the entity to which that key is associated.

The public key and identifier have together been signed by a certification authority, and this signature has been placed on the certificate as well.

Signing takes place by means of a private key K-CA that belongs to the certification authority.

Page 7: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Using a public-key certificate works as follows.

Assume that a client wishes to ascertain that the public key found in the certificate indeed belongs to the identified entity.

It then uses the public key of the associated certification authority to verify the certificate's signature. If the signature on the certificate matches the (public key, identifier )-pair, the client accepts that the public key indeed belongs to the identified entity.

Page 8: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Hierarchical trust models Privacy Enhanced Mail (PEM) uses a

three-level trust model in which lowest-level certification authorities can be authenticated by Policy Certification Authorities (PCA), which in turn can be authenticated by the Internet Policy Registration Authority (IPRA).

If a user does not trust the IPRA, or does not think he can safely talk to the IPRA, there is no hope he will ever trust e-mail messages to be sent in a secure way when using PEM.

Page 9: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Lifetime of Certificates

revoke a certificate1. One common approach is

with a Certificate Revocation List (CRL) published regularly by the certification authority.

Whenever a client checks a certificate, it will have to check the CRL to see whether the certificate has been revoked or not.

Page 10: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

2. An alternative approach is to restrict the lifetime of each certificate.

The validity of a certificate automatically expires after some time.

If for whatever reason the certificate should be revoked before it expires, the certification authority can still publish it on a CRL.

Page 11: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

3. A final extreme case is to reduce the lifetime of a certificate to nearly zero.

In-effect, this means that certificates are no longer used; instead, a client will always have to contact the certification authority to check the validity of a public key.

As a consequence, the certification authority must be continuously online.

Page 12: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Secure Group Management

Page 13: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at
Page 14: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Authorization Management

Page 15: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Capabilities and Attribute Certificates

Page 16: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

The slide shows the structure of a capability in the Amoeba system. The fields as shown are used as follows:

Server port: a machine-indepentent identifier of the object's server

Object: an identifier for the actual object Rights: access rights of the capability's holder Check: a field used to make the capability

unforgeable. It is randomly generated and stored in both the capability and in an internal table of the server. Thus, when a client requests an operation, it sends a copy of the capability to the server. The server uses the check field to verify the client's capability.

Page 17: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Restricted Capability When an object is created, the capability is

returned to a client with all of the rights bits turned on. The client may then request that the server generate a restricted capability, which is shown in the slide:

The check field is XORed with the new rights value to create a new copy of the check field. That is placed into the restricted capability and sent back to a client.

The original check field is stored with the server.

Page 18: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at
Page 19: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at

Delegation

Page 20: SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at