1 / 20

SECURITY MANAGEMENT

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.

smann
Download Presentation

SECURITY MANAGEMENT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Key Establishment

  3. Diffie- Hellman key exchange

  4. Key Distribution

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

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

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

  8. Lifetime of Certificates • revoke a certificate 1. 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.

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

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

  11. Secure Group Management

  12. Authorization Management

  13. Capabilities and Attribute Certificates

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

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

  16. Delegation

More Related