Encryption Standards/Apps
description
Transcript of Encryption Standards/Apps
![Page 1: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/1.jpg)
X.509
Topics
PGP
S/MIME
Kerberos
![Page 2: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/2.jpg)
Directory Authentication Framework• X.509 is part of the ISO X.500 directory standard. • used by S/MIME, SSL, IPSec, and others
1) a standard certificate format
Important Components of X.509
2) a standard scheme for implementing certificate authorities
3) standard authentication protocols
4) a digital signature “standard” • no particular cipher is dictated, but RSA is recommended• no particular hash is dictated.
![Page 3: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/3.jpg)
VersionCertificate Serial #
Dig. Sig. (algorithm & parameters)Issuer name (CA)
Start DateEnd Date
Subject name
Public Key (algorithm & parameters)Public KeyIssuer ID
Subject IDExtensions
Dig. Sig. (algorithm & parameters)Digital Signature
![Page 4: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/4.jpg)
• Simple authentication occurs when two subjects are issued certificates from one CA.
• CAs issue certificates to subjects.
ExampleA
B C
D
Ole
Lena
Sven
NotationA, B, C, and D are CAs.Ole, Sven and Lena are subjectsCertificate: Issuer «Subject»
D «Ole» D «Sven»
C «Lena»
Suppose Ole wants to validate Sven.
... but what if Ole wants to send a message to Lena?
• A subject can transmit his/her certificate to a different subject.
![Page 5: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/5.jpg)
Example (cont’d)A
B C
D
Ole
Lena
Sven
NotationA, B, C, and D are CAs.Ole, Sven and Lena are subjectsCertificate: Issuer «Subject»
D «Ole» D «Sven»
C «Lena»
For Ole to validate Lena
B «D»D «B»
General authentication requires CAs to exchange certificates, supporting certificate chaining.
A «B»B «A»
A «C»C «A»
Note: two kinds of certificates: forward - holder is subject, issuer is another CA reverse - holder is issuer, subject is another CA
He obtains ___________ & validates B as a CA using D’s public key.He obtains ___________ & validates A as a CA using B’s public key.He obtains ___________ & validates C as a CA using A’s public key.He obtains ___________ & validates Lena using C’s public key.
Certificate Chain:
![Page 6: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/6.jpg)
Assume that Ole wishes to authenticate Lena. There are three possible protocols.
One Way
NotationSig denotes a digital signature (an MD encrypted
with the sender’s private key)TimeStamp consists of optional generation time
and expiration timenonce is a random number unique until expiration time
TimeStamp1 || nonce1 || IDLena || Sig || E(SessionKey, KLenaPub)
Ole LenaThis establishes a) the integrity of the message b) the identity of the sender (Ole) c) that the message is intended for Lena (confidentiality)
Notes: 1) a message could also be sent this way (protected by Sig). 2) session key is optional.
![Page 7: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/7.jpg)
Two WayTimeStamp1 || nonce1 || IDLena || Sig || E(SessionKey, KLenaPub)
Ole Lena
This establishes additionally a) the integrity of the reply b) the identity of the receiver (Lena) c) that the message is intended for Ole
Ole Lena
TimeStamp2 || nonce2 || IDOle || Sig || E(SessionKey, KOlePub)
Three WayTimeStamp1 || nonce1 || IDLena || Sig || E(SessionKey, KLenaPub)
Ole Lena
Ole Lena
TimeStamp2 || nonce2 || IDOle || nonce1 || Sig || E(SessionKey, KOlePub)
Ole Lena
nonce2 || Sig
This echos nonces to avoid replay w/o time stamps.
![Page 8: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/8.jpg)
• 1991 - PGP created by Phil Zimmerman
• widely-used secure email standard
• 1996 purchased by Network Associates
Brief History
Ring of Trust• Each user maintains a trusted keyring (public keys) and an owned keyring (private keys).
• Keys may be retrieved from a server or included at the end of a message.
• Each key is signed by owner (and possibly others).
• Trust is based on who signed the key.
• Subject discretion ultimately determines who to trust.
• Keys can be revoked by the owner.
![Page 9: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/9.jpg)
• create a random session key (for symmetric cipher)
• encrypt/decrypt session key using public key (RSA or Diffie-Hellman)
• encrypt/decrypt message using session key (IDEA, 3DES or CAST-128)
Potential PGP Operations
• generate & encrypt (or decrypt) MD (SHA-1) using private key
• attach encrypted session key (as a digital signature) to a message
• transmit message
![Page 10: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/10.jpg)
Private Key RingTime Stamp
Key ID
Public Key (of pair)
Private Key (of pair)
User’s ID
least significant 64 bits of public key
usually the user’s email address
Public Key RingTime Stamp
Key ID
Public Key (of pair)
User’s ID
![Page 11: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/11.jpg)
PGP uses the concept of a one-time session key
Typical Message Format (from Lena to Ole)ID of KOlePub
E( SessionKey, KOlePub )
TimestampID of KLenaPub
Leading two octets of MD
E( MD, KLenaPriv )
File NameTimestamp
Data
This part is firstcompressed (zip)then encrypted withSessionKey
The entire transmissionis encoded in radix-64.
![Page 12: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/12.jpg)
Why use a one-time (session) key?
![Page 13: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/13.jpg)
Certificate Processing • Uses X.509v3 certificates
S/MIME -- Secure / Multipurpose Internet Mail Extensions
Originally developed by RSA
• Responsibility for maintaining certificates is local.
• Certificates are signed by a Certificate Authority
Typical Functions• The client must generate keys.
• A pair of generated keys are registered with a CA.
• The CA supplies certificates in X.509 format.
• The client can maintain a list of trusted certificates.
• CAs - VeriSign, GTE, Nortel, U.S. Postal Service
![Page 14: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/14.jpg)
Class 1
Class 2
Class 3
Algorithms• must support SHA-1 (should support MD5 for backward compatibility)
• must support DSS (should support RSA-512 and RSA-1024 for digital signatures)
• must support RC2/40 with one-time key and should support 3DES
• session key encryption with Diffie-Hellman is preferred (RSA is possible)
VeriSign Certificates Classes
VeriSign required unambiguous nameand email address, PIN is emailed to user
VeriSign does online database search andsends digital ID & PIN to postal address
Client must prove identity via notarypublic or appear in person
Web browsers,email
online subscriptions,secure email
banking, secure database,membership-basedservices, e-commerce
![Page 15: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/15.jpg)
• Kerberos is an authentication system - authenticating users and services.
• It was originally developed as part of Project Athena - MIT.
• Kerberos relies upon a centralized Kerberos server per realm.
• A kerberos server must contain a database of user IDs and hashed passwords.
• A kerberos server must share a secret key with registered servers.
• Multi-realm communication is also possible.
• The client can maintain a list of trusted certificates.
![Page 16: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/16.jpg)
Weaknesses
Alternative 1
NotationOle is the clientAS is the authentication/Kerberos serverpwdC is the password for CIPC is the IP address of CkeyS key shared by AS and server S
IDOle || pwdOle || IDS)
Ole AS
Ole AS
TicketS ==
Ole S
Ticket || IDOle E( IDOle || IPOle || IDs, keyS )
![Page 17: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/17.jpg)
Weaknesses 1) lifetime 2) server is never authenticated to the client
Alternative 2IDOle || IDTGS
Ole AS
Ole ASTicketTGS
Ole TGS
IDOle || IDS || TicketTGS
E( IDOle || IPOle || IDTGS || Lifetime1 || TimeStamp1 , keyOle)
loginTGS -- ticket granting server
Ole TGSTicketS
E( IDOle || IPOle || IDS || Lifetime1 || TimeStamp2 , keys )
key based on Ole’s pwdto obtain service
Ole S
IDOle || TicketS once per service session
![Page 18: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/18.jpg)
Version 4 protocolIDOle || IDTGS || TimeStamp1
Ole AS
Ole AS
Ole TGS
IDS || TicketTGS || E( IDOle || IPOle || TimeStamp3, keyOle&TGS )
E( KeyOle&TGS || IDOle || IPOle || IDTGS || TimeStamp2 || Lifetime2, keyTGS)
login
Ole TGS
E( KeyOle&S || IDOle || IPOle || IDS || TimeStamp4 || Lifetime4, keys )
to obtain service
Ole S
once per service session
E( KeyOle&TGS || IDTGS || TimeStamp2 || Lifetime2 || TicketTGS, keyOle )
TicketTGS ==
E( KeyOle&S || IDS || TimeStamp4 || TicketS, keyOle&TGS )
TicketS ==
TicketS || E( IDOle || IPOle || TimeStamp5, keyOle&S )
Ole SE( 1 + TimeStamp5, keyOle&S )
![Page 19: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/19.jpg)
Version 5 protocol
Ole S
once per service session
Options || TicketS || E( IDOle || RealmOle || TimeStamp2 || subkey || seq#, keyOle&S )
Ole SE( TimeStamp5 || subkey || seq#, keyOle&S )
Options || IDOle || RealmOle || IDTGS || Times || Nonce1
Ole AS
Ole AS
E( Flags || KeyOle&TGS || RealmOle || IDOle || IPOle || IDTGS || Times, keyTGS)
login
E( KeyOle&TGS || Times || Nonce1 || RealmTGS || IDTGS, keyOle )
TicketTGS ==
RealmOle || IDOle || TicketTGS ||
Ole TGS
Options || IDS || Times || Nonce2 || TicketTGS || E( IDOle || RealmOle || TimeStamp1, keyOle&TGS )
Ole TGS
E( Flags || KeyOle&S || Realm || IDOle || IPOle || Times, keys )
to obtain service
E( KeyOle&S || Times || Nonce2 || RealmS || IDS, keyOle&TGS )
TicketS ==
RealmOle || IDOle || TicketS ||
![Page 20: Encryption Standards/Apps](https://reader035.fdocuments.in/reader035/viewer/2022062521/568139d4550346895da1870f/html5/thumbnails/20.jpg)
• Version 4 required the use of DES - Version 5 supports the use of algorithm tags
• Version 4 used an 8-bit lifetime - restricted to approx. 21 hrs. - Version 5 more flexible.
• Version 5 also adds realms
• Both versions are somewhat vulnerable to password attacks, because keys are based on passwords.