06 암호의 응용 (2)
- 전자우편 보안
정보보호
E-mail Security
Introduction to E-mail
Privacy Enhanced Mail (PEM)
The Certification System
Pretty Good Privacy (PGP)
Secure Multipurpose Internet Mail
Extensions (S/MIME)
Introduction to E-mail
E-mail is one of the most popular Internet applications
Asynchronous (=> no session => no handshaking)
Fast
Easy to distribute
Inexpensive
Modern e-mail messages can include hyperlinks,
HTML formatted text, images, sound, and even video
Accessible from any host connected to the Internet
A Typical E-mail Journey
1. Starts its journey in the sender’s user agent
2. Travels to the sender’s mail server
3. Then travels to the recipient’s mail server
4. Deposited in the recipient’s mailbox
5. The recipient wants to access the messages in his mailbox
6. The mail server containing his mailbox
authenticates him (with user name and password)
7. Then sends the message to the recipient’s user
agent
Existing E-Mail System
Intermediate relay point Recipient’s mailbox host User
agent Editor
Mail transfer Agent (SMTP) Originator at a multiuser host
User agent
Recipient at a workstation
Mail transfer Agent (SMTP relay)
Mail transfer Agent (SMTP) SMTP
(RFC 821)
SMTP (RFC 821)
Retrieval (e.g.
POP3)
The Simple Mail Transfer Protocol (SMTP)
Defined in RFC 821 (dates back to 1982 )
The principal application-layer protocol for the internet electronic mail
Uses the reliable data transfer service of TCP at port 25
Possess certain “archaic” characteristics
(such as the 7-bit ASCII restriction)
Example to SMTP
S: 220 hamburger.edu C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]>
S: 250 [email protected]… Sender ok C: RCPT TO: <[email protected]>
S: 250 [email protected]… Recipient ok C: DATA
S: 354 Enter mail, end with “.” on a line by itself C: Do you like ketchup?
C: .
S: 250 Message accepted for delivery C: QUIT
S: 221 hamurger.edu closing connection
a client C, which its host name is crepes.fr
a server S, which its host name is hamburger.edu
Header Format
Defined in RFC 822
Headers containing peripheral information precedes the body of the message itself
Specifies the exact format for mail header lines as well as their semantic interpretations
After the message header, a blank line follows, then the message body in ASCII follows
The message terminates with a line containing
only a period
Example to E-mail Message
From: [email protected] To: [email protected] Subject: Mail header format
Message body (in ASCII)
.
Multipurpose Internet Mail Extensions (MIME)
RFC 822 is not sufficiently rich enough for multimedia messages
Include additional headers in the
message, which are defined in RFC 2045/2046
This topic will be addressed later in the
S/MIME section
The Security Issue (1)
Initial specification of internet e-mail did not address security issues
In particular, security mechanisms to provide data
confidentiality, authenticity, integrity and non-repudiation were missing
E-mail service is asynchronous
All the regular security protocols (such as IPSEC, SSL, etc.) are synchronous
PEM, S/MIME and PGP come to help
Each message is a one-time independent event with its own
one-time symmetric key
The Security Issue (2)
Why not simply use the regular
synchronous security protocols to protect the message while en route between
intermediate stations ?
Security services should be added between the two end users (no exposure in the middle)
The secure services were build on an existing
mail system (SMTP mail servers)
Privacy Enhanced Mail (PEM) Introduction
Primary goal of PEM is to add security services for e-mail users in the internet community
Began in 1985 as an activity of the Privacy and Security Research Group (PSRG)
Defined in RFCs 1421/1422/1423/1424
Consists of extensions to existing
message processing software plus a key
management infrastructure
PEM Security Services
Integrity
which ensures a message recipient that the message has not been modified en route.
Authenticity
which ensures a message recipient that a message was sent by the indicated originator.
Non-repudiation
which allows a message to be forwarded to a third party, who can verify the identity of the originator.
Confidentiality (optional)
which ensures a message originator that the message text
will be disclosed only to the designated recipients.
PEM Overview
Compatible with RFC 822 message processing conventions
Transparent to SMTP mail relays
Uses symmetric cryptography to provide (optional) encryption of messages
The RFCs strongly recommend the use of asymmetric cryptography (for digital
signatures, certificates and encryption of the symmetric key) because of its ability to
support vast distributed community of users
PEM Overview (contd.)
The use of X.509 certificates is the base for public key management in PEM
This certification hierarchy supports
universal authentication of PEM users
PEM can be used in a wider range of
messaging environments (other than RFC
822 and SMTP)
Integration Of PEM Into Existing Mail System
Intermediate relay point Recipient’s mailbox host User
agent Editor
Mail transfer Agent (SMTP) Originator at a multiuser host
User agent Recipient at a workstation
Mail transfer Agent (SMTP relay)
Mail transfer Agent (SMTP) SMTP
(RFC 821)
SMTP (RFC 821)
Retrieval (e.g.
POP3) PEM
filter
PEM module
PEM Message Submission:
Message Processing
Begin privacy enhanced message
End privacy enhanced message Encapsulated header:
Contains authentication, integrity, and (optional) encryption control fields and
related information Blank line Encapsulated text:
(Encrypted)
User message text and optional Replicated header fields User provides recipient
address and other data (e.g. “Subject”) for enclosing header User provides address information needed to perform encryption
Plaintext of user message requiring privacy
enhancement
Enclosing header
RFC 822 header fields
Encapsulated message
All data between the privacy enhanced message boundaries is represented here, and may be interspersed with unprotected plaintext
PEM Message Processing
Plaintext message
“SMTP” canonicalization
MIC calculation and (optional) encryption
6-bit encoding and line length limiting
Processed message Step 1
Step 2
Step 3
PEM Message Processing – Step 1
Uses the canonicalization specified by SMTP to ensure a uniform presentation syntax among a heterogeneous collection of computer systems .
The shortcoming is that it restricts the input to 7-bit ASCII .
The reason is that the Internet e-mail
imposes the same restrictions.
PEM Message Processing – Step 2
A MIC is calculated over the canonicalized message to permit uniform verification in the heterogeneous environments .
The canonical (padded as required) message text is then (optionally) encrypted using a per- message symmetric key .
The encryption action is performed only if the
message is of type ENCRYPTED .
PEM Message Processing – Step 3
Renders an ENCRYPTED or MIC-ONLY message into a printable form suitable for transmission via SMTP.
This encoding step transforms the
(optionally encrypted) message text into a restricted 6-bit alphabet.
A MIC-CLEAR messages are not subject
to any portion of the third processing step.
PEM Message Types
ENCRYPTED is a signed, encrypted and encoded (in step 3) message .
MIC-ONLY is a signed , but not encrypted, encoded message .
MIC-CLEAR is a signed, but not encrypted, and message that is not encoded .
Specially so it can be sent to a mixed set of
recipients, some of whom use PEM and some do
not.
PEM Message Submission: Header Construction (1)
From: [email protected] To: [email protected]
Subject: Encrypted PEM message
--- BEGIN PRIVACY-ENHANCED MESSAGE
- --- -
Proc-Type: 4, ENCRYPTED Content-Domain: RFC822
DEK-Info: DES-CBC, BGFA799HTS347KGKL0
Originator-Certificate:
3 yhtrwhhj57jw5jw6w7u6juj6uu45yjj5645w4y4y5yqy Issuer-Certificate:
Eth46u5kw57kwuw3jwjw465iw6uw57uw6u4q6jj6646
Version & type
Standard RFC 822 Header
Conforms to
Msg encryption params (for example, IV)
Originator certificate
Issuer certificate
PEM Message Submission: Header Construction (2)
MIC-Info: RSA-MD5, RSA,
Sdhdsh453hwe5yyh5ywjuhs5yahhaehjue78iok67k Recipient-ID-Asymmetric:
Agw56ywjq45y2jqhj4yuq4hjq4yq3yy3yewghew5y3 Key-Info: RSA,
Adshw45w5j7w57j5u46yu5yq46ju46juqyuq4u5y35hj
Dfghj56er656uw6u64uu45yw46u5wjwu5i56u57i5wuiw5u W46uw56uueueri5u6w56uw46u5wu56uw56u56u5
--- END PRIVACY-ENHANCED MESSAGE
---
Digital signature MIC & Dig.Sig algo
Recipient’s id Public key algo
Encrypted message key
Encrypted message Blank line
PEM Message Delivery Processing (1)
Recipient receives a PEM message
Scans the PEM header for the version and the type (ENCRYPTED, MIC-ONLY, MIC-CLEAR)
If ENCRYPTED or MIC-ONLY then decode the 6- bit encoding back to ciphertext or canonical
plaintext form
If ENCRYPTED then decrypt the symmetric
message key using the private component of his
public key pair and decrypt the message using
the symmetric message key
PEM Message Delivery Processing (2)
Validate the public key of the sender by validating a chain of certificates
Validate the digital signature using the
public component of the public key of the sender
The canonical form is translated into the
local representation and presented to the
recipient
The Certification System
A public key X.509 certificate
is a digitally signed data structure used to securely bind a public key to a name and to specify who vouches for the binding
The signature to the certificate applied by the issuer
using the private component of his public key pair and appended after the certificate fields
One validates a certificate by computing the one-way hash function over the certificate,
uses the public key of the issuer to decrypt the value in the appended signature and compare the two resulting values
X.509 Certificate
Certificate: = SIGNED SEQUENCE {
version[0] Version DEFAULT v1988, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier,
issuer Name, validity Validity, subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo }
Uniquely identifies this certificate
Dig.sig & hash func algo & params
Issuer ID
Start & end valid times
Subject name Public key of the subject, algo ID &
params
The Internet Certification System (1)
The user need to possess the public key of
the issuer of the certificate in order to validate the certificate
The issuer will also have a certificate, and thus the process of certificate validation is recursive and implicitly defines a directed certification graph
X.509 defines a Certification Authority (CA)
as “an authority trusted by one or more users
to create and assign certificates”
The Internet Certification System (2)
Different CAs can issue certificates under different policies, for example, varying degrees of assurance in vouching for
certificates
The root of the certification graph is the Internet PCA Registration Authority (IPRA)
The IPRA is a reference point from which all certificates can be validated
The IPRA issues certificates to a second layer of entities called Policy Certification Authorities (PCA), which, in turn, issue certificates to CAs
CAs can issue certificates to (subordinate) CAs or directly to
users
Example to a Typical Internet Certification Hierarchy
IPRA
High assurance
Residential Mid-level assurance
Persona
BBN Louisiana New York MIT HUJI Persona
User BBNCD New Orleans User User LCS User User User User
User User User
User User
User User
User
PEM Summery
PEM represents a major effort to provide security for an application that touches a vast number of users within the Internet and beyond
PEM was designed to have backward compatibility with existing mail system
PEM depends on a successful establishment of the certification hierarchy that underlies
asymmetric key management
Problem : PEM does not support security services
to multimedia files (MIME)
Next :
Pretty Good Privacy
What are we going to do ?
Background & Concept
Why Is PGP Popular?
PGP’s algorithms
Operational Description
Inside look on operations
Key Management
The problem & Solution
Web Of Trust
Pretty Good Privacy
First released in 1991, developed by Phil Zimmerman, provoked export control and patent infringement
controversy.
PGP provides a confidentiality and authentication service
can be used for electronic mail and file storage applications.
Available as plug-in for popular e-mail clients, can also be used as stand-alone software.
microsoft exchange
outlook
Why Is PGP Popular?
Based on well known algorithms - “The main idea”
These algorithm have survived extensive public review and are considered extremely secure.
Integrated these algorithms into a general-purpose application
It is availiable free on a variety of platforms (Windows, UNIX, Macintosh, etc.)
Open and free code.
Wide range of applicability from corporations that wish to select and enforce a standerized secure to individuals
Independent – meaning Not developed or controlled by governmental or standards organizations
Based on mutual trust between clients
Operational Description
Actual operations of PGP consist of five services:
Authentication
DSS/SHA or RSA/SHA
Confidentiality
CAST or IDEA or RSA or 3DES
Compression
A message may be compressed, for storage or transmission using ZIP
E-mail compatibility
To provide transparency for e-mail applications, an encrypted message
may be converted to an ASCII using Radix-64
Segmentation
To accommodate maximum message size limitations.
Authentication/Digital Signature
Sender creates a message
Sender generates a hash code of the message
uses SHA-1 algorithm in order to generates 160-bit hash code
Hash code encrypted with RSA (sender’s private key)
the result is prepended to the message
Receiver recover the hash code
uses RSA with the sender’s public key
Receiver generates new hash code of the message and compares the two codes.
If the two match, the message is accepted as authentic.
Note:
PGP only encryptes the hash-code of the message:
more efficient in running time and in transfer time
Authentication/Digital signature
Source A Destination B
Message
M H EP | |
Private key KRa
ZIP UNZIP DP
Compare
H Message
M
Public key KRb
PGP Signed Message
---BEGIN PGP SIGNED MESSAGE--- Hash: SHA1
This is simply the text of the message.
It has not been encrypted, simply signed
---BEGIN PGP SIGNATURE---
Version: PGPfreeware 6.5.3 for non-commercial use
<http://www.pgp.com>
iEYEARECAAYFAj5Ha6AACgkQ99/KQPj2cRNHsQCffKf64LwWQMfRIiKU fs6QrokB7twAnR5gDobzGapPgyLKQ0gLklj1WIIp=gXad
---END PGP SIGNATURE---
Confidentiality/Encryption
Sender generates message and also a session key
The session key is a random 128-bit number to be used as a session key for this message only
Sender encryptes the message
Uses CAST-128 (IDEA or 3DES) algorithm with the session key
Sender encryptes the Session key with RSA and prepended to the message
Receiver decrypt the session key
uses RSA with its private key
Receiver decrypt the message with the Session key
Note:
PGP does not simply using RSA to encrypt the message directly.
Using CAST128 force us to share a key - using public-key algorithm solves the session key distrinution problem.
Given “Store-and-forward” nature of e-mail, the use of handshaking to assure that both sides have the same session key is not practical.
The use of on-time conventional keys strengthens what is already a strong conventional
encryption approach. only a small amount of plaintext is encrypted with each key and there is no relationship among keys.
Confidentiality/Encryption
Public key KUb
Messa ge
M
Session key Ks
EC
EP
| | ZIP
Messa ge
M
DC
Session key Ks
DP
Private key KRb
Messa ge
M
UNZIP
Source A Destination B
Confidentiality &
Authentication
M H EP | |
Private key KRa
ZIP
Public key KUb
EC
EP
| | DC
Session key Ks
DP Private
key KRb
M
UNZIP
Session key
Ks DP
Compare H
M
Public key KRb
Source A Destination B
•PGP first signs the message and then encrypts it:
- more convenient to store a signature with a plaintext version of a message
- for purposes of third party verification
Compression
Saving space both for e-mail transmission and for file storage
PGP uses ZIP to compress the message
PGP compress the message after applying the signature but before message encryption:
Signature Zip Encryption
One can store only the uncompressed message with the signature for future verification. In case the order was opposite:
it would be necessary either to store a compressed version of the message or to recompress the message each time when verification is required
Compression algorithms are different – the algorithm is not deterministic.
sign after compress will would constrain all PGP implementations to the same compression algorithm
Encryption is applied after compression to strengthen cryptographic security
compressed message has less redundancy than original plaintext
Example of ZIP (LZ77) Scheme
The brown fox jumped over the brown foxy jumping frog
The brown fox jumped over
0b26d13dy
0b27d5ding frog
13 5
26
27
•The main assumption is that words and phrases within a text
stream (image patterns I the case of GIF) are likely to be repeated
• When a repetition occurs, the repeated sequence can be replaced by a short one
• Over time, codes are reused to capture new sequences
E-mail Compatibility
When PGP is used, At least part of the block to be transmitted is encrypted
The resulting block will consist of a stream of arbitraty 8-bit octets
Many electronic mail systems only permit the use of blocks consisting of ASCII text
To provide transparency for e-mail applications, an
encrypted message may be converted to an ASCII string using radix 64 conversion
The use of Radix-64 expands a message by 33%
In fact, the compression should be more than enough to compensate for the radix-64 expansion
Encoding Binary Data into Radix-64 Format
The scheme used is radix-64 conversion, which expands the message by 33%.
Radix-64 blindly converts the input stream to radix-64 format regardless of content, even if the input happens to be ASCII text.
certain level of confidentiality - if the message is signed but not encrypted, the output will be unreadable to the casual observer
Radix-64 Conversion Table
6-bit Value Character
Encoding
6-bit Value Character
Encoding
6-bit Value Character
Encoding
6-bit Value Character
encoding 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
A B C D E F G H I J K L M N O P
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Q R S T U V W X Y Z a b c d e f
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
g h i j k l m
n o p q r s t u v
48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 (pad)
w x y z 0 1 2 3 4 5 6 7 8 9 + /
=
Radix-64 Encoding
Segmentation and Reassembly
E-mail facilities are often restricted to a maximum message length
for example 50,000 octets.
Longer messages must be broken up into segments, which will be mailed separately.
PGP automatically subdivides a message that is too large into segments that are small enough to send via e-mail.
The segmentation is done after all of the other processing, including the Raidx-64 conversion.
thus, the session key component and signature component appear only once
The receiver strips off all e-mail headers and reassemble the block.
Key Requirements
PGP makes use of four types of keys:
one-time session conventional keys,
public keys,
private keys,
passphrase-based conventional keys
Three seperate requirements:
A means of generating unpredictable session keys is needed
Any user may have multiple public-key/private-key pairs
may wish to change his key pair from time to time
in order to interact with different groups
simply to enhance security by limiting tha anount material encrypted with any one key
some means is needed for identifying particular keys
Each PGP entity must maintain data base of:
a file of its own key pairs
a file of public keys of correspondents
Session Key Generation
The Problem : generating unpredictable session keys
Session keys are generated using CAST-128 itself:
This is a PGP specific random number generation technique
getting as input:
two 64-bit blocks that are treated as plaintext to be encrypted.
based on keystroke stream generated by the user
128-bit key
random input that also combined with previous session key output from CAST-128.
The result, scrambling of CAST-128, is to produce a sequence of session keys that is effectively unpredictable
Key Identifiers
The Problem: user may have multiple public-key/private-key pairs
One simple solution would be to transmit the public key with the message.
Would work but an RSA key may be three hundreds of decimal digits in length (1024 bits)
PGP solution associate a short identifier with each public key that is unique.
then only the much shorter key ID would need to be transmitted.
The key ID associated with each public key consists of its least significant 64 bits
That is the ID of KU is (KU mod 264)
Format of PGP Message
Session Key Component
Signature
Message
EKUb
EKRa
ZIP Eks R64
Timestamp
Key Id of Senders Public Key
Leading Two Octets of Message Digest
Message Digest Filename
Time Stamp Data
Session Key
Key Id of Recipients Public Key
PGP Key Rings
The problem: must maintain a database in order to supports multiple public/private keys.
The Solution : Keys stored locally in a PGP Key Ring – essentially a database of keys.
Two rings:
Private-key ring: stores the public/private key pairs owned by that node
Public-key ring: stores the public keys of other users known at this node
Private keys stored in encrypted form; decryption
key determined by user-entered passphrase.
Key Rings
Timestamp Key ID* Public Key Encrypted
Private Key User ID*
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Ti KUi mod 264 KUi EH(Pi)[KRi] User i
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Private-Key Ring
Key Rings
Timestamp Key
ID* Public
Key Owner
Trust User
ID* Key
Legitimacy Signature(s) Signature Trust(s)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Ti KUi
mod 264
KUi User
i
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Public-Key Ring
Message Generation
Public key
KRb
IDb Select
Public-Key ring
Message M
H EP | |
Message digest
Message
RNG
Session key
Ks
EC
Signature + message
EP
Encrypted Signature + message
| |
IDa Select
Private-Key ring
DC
Passphase H
Encrypted Private key
Output Key
ID
Private key
KRa
Reception
Receiver's key ID Encrypted Session key
Encrypted Message +
Signature
Public key
KRb Select
Public-Key ring
DP
Select
Private-Key ring
DC
Passphase H
Encrypted Private key
Session key
Ks DP
Private key
KRb DC
Sender’s Key ID Encrypte
d Digest Message
Compare
H
Public Key Management Problem
The Problem: A’s key ring contains a
public key attributed to B but that the key is, in fact, owned by C
Two threats now exist:
C can send messages to A and fake B’s
signature, so that A will accept the message as coming from B !
Any encrypted message from A to B can be
read by C !
Public Key Management Problem (cont.)
Possible solutions:
Physically get the key from B
Verify a key by telephone
Obtain B’s public key from a mutual trusted individual
Obtains B’s public key from a trusted certifying authority
That would violate PGP’s spirit as an E-mail security scheme for the masses:
It should be possible for people to exchange keys
electronically with others whom they have never met and may not even know
Every one who uses this scheme trusts the central
authority
PGP Key Management
PGP Solution: adopts a different trust model – the “web of trust”
No centralised authority like a root of trust !
The concept of the web of trust:
The concept: Individuals sign one another’s public keys and create an interconnected community of public-key users.
These “certificates” are stored along with keys in key rings
A signature testifies that the User ID associated with this public key is valid
A signature is formed using the private key of the signer
PGP computes a trust level for each public key in key ring.
Users take part in the assignment of the trust level
Trust in Public Key Ring
Each user collects signed keys and stores these in the public- key ring.
Each entry in the ring has:
Key legitimacy field
Measures the degree to which this PGP user trusts that the key is valid for its user. The higher the level of trust, the stronger is the binding of this user ID to this key
Signature trust field
Measures how far the PGP user trusts the signer to certify public keys.
(The key legitimacy field for an entry derives from the signature trust fields.)
Owner trust field
Indicates the degree to which this PGP user trusts the key's owner to sign other public-key certificates. PGP doesn't compute this level of trust; the PGP user assigns it. You can think of a signature trust field as a cached copy of the owner trust field from another entry.
Trust in Public Key Ring
Key Legitimacy Field (computed by PGP)
Signature Trust Field (copies of OTF)
Owner Trust Field (assigned by the user)
Timestamp Key
ID* Public
Key Owner
Trust User
ID* Key
Legitimacy Signature(s) Signature Trust(s)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Ti KUi
mod 264
KUi Trust flagi
User i Trust flagi
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Public-Key Ring
Adding a new public key to your public-key ring:
Owner trust field: (signed other keys)
If you own the key - ultimate trust is automatically assigned.
If you don’t own the key - PGP asks the user:
unknown, untrusted, marginally trusted, or completely trusted
Signature trust field: (trusts the signer)
PGP searches the public-key ring to see if the author of this signature is among the known public-key owners.
If so, the owner trust value for this owner is assigned to the signature trust field for this signature.
OWNERTRUST SIGTRUST
If not, an unknown-user value is assigned.
key-legitimacy: (the key is valid for its user)
On the basis of the signature trust fields present in this entry.
If at least one signature has a value of ultimate trust, then the key legitimacy value is set to complete
Otherwise, PGP computes a weighted sum of the trust values.
1/X is given to signatures that are always trusted
1/Y is given to signatures that are usually trusted
X and Y are user-configurable parameters.
PGP Trust Model Example
Revoking Public Keys
When exposure suspects or simply avoiding the use of the same key for an extended period
The owner issue a key revocation certificate
Signed by the owner , with the corresponding private key
Same form of normal signature certificate but includes an indicator that the purpose of this certificate is to revoke the use of this public key
The owner should disseminate this certificate as widely and as quickly as possible opponent
NOTE:
An opponent who has compromised the private-key of an owner can also issue such a certificate. However, this would deny the opponent as well as the legitimate owner the use of the public Key – seems much less likely threat.
PEM과 PGP 비교
PEM PGP
• IETF
• Internet 표준안
• 이론 중심
• 중앙집중화된 키 인증
• 구현이 어렵다
• 익명의 메세지를 허용치 않음
• 높은 보안성 (군사용, 은행 시스템)
• 많이 사용되지 않음
• Phil Zimmerman
• 응용 프로그램
• 실세계 중심
• 분산화된 키 인증
• 구현이 용이함
• 익명의 메세지를 허용함
• 일반 용도의 보안성
• 많이 사용
Next :
S/MIME
S/MIME - Overview
After the development of PEM industry working group led by RSA Security, Inc. started to develop another specification for conveying digitally signed and/or encrypted and digitally enveloped data in accordance to the MIME message formats.
S/MIME (Secure/Multipurpose Internet Mail Extension) is a security enhancement to the MIME Internet e-mail format standard.
S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP.
S/MIME is likely to emerge as the industry standard for commercial and organizational use, while PGP will remain the choice for
personal e-mail security for many.
S/MIME - Overview
S/MIME provides the following cryptography security services:
Authentication.
Message Integrity. By using digital signing
Non-repudiation of origin.
Privacy and data security. By using encryption
There are three versions of S/MIME:
S/MIME version 1 (1995) - was specified and officially published in 1995 by RSA Security, Inc.
S/MIME version 2 (1998) - was specified in a pair of informational RFC documents - RFC 2311 and RFC 2312 - in March1998.
The work was continued in the IETF S/MIME Mail Security (SMIME) WG and resulted in S/MIME version 3 (1999) specified in RFCs 2630 to 2634 in June 1999.
MIME
RFC 822 defines a format for text messages that are sent using electronic mail.
SMTP/RFC822 scheme limitations:
SMTP cannot transmit executable files or other binary files.
SMTP cannot transmit text data that includes national language characters because these are represented by 8-bit codes with values of 128 decimal or higher, and SMTP is limited to 7-bit ASCII.
SMTP servers may reject mail message over a certain size.
SMTP gateways that translate between ASCII to EBCDIC suffer translation problems.
Some SMTP implementations do not adhere completely to the SMTP standard defined in RFC 822.
MIME (contd.)
MIME specification includes the following elements:
Five new message header fields.
These fields provide information about the body of the message.
A number of content formats are defined,
thus standardizing representations that supports multimedia e- mail.
Transfer encodings are defined
that enable that protect any content format to be altered by the mail system.
MIME provides a standardized way of dealing with a wide variety of information representations in a
multimedia environment.
MIME (contd.)
Here is a summary of the different MIME content types:
Type Subtype Description
Text
EnrichedPlain Unformatted text (ASCII or ISO 8859).Provides greater format flexibility.
Multipart
MixedParallel Alternative Digest
The different parts are independent but are to be transmitted together. Should be presented to the receiver in their original order.
Differs from mixed only in that no order is defined.
The different parts are alternative versions of the same information.
Similar to Mixed but the default type/subtype of each part is message/rfc822.
Message
rfc822Partial External body
The body is itself an encapsulated message that conforms to RFC822.
Used to allow fragmentation in a transparent way to the recipient.
Contains a pointer to an object exists else where.
MIME (contd.)
Type Subtype Description
Image
Jpeggif The image is in JPEG format.The image is in GIF format.
Video
Mpeg MPEG format.Audio
Basic Single-channel 8-bit ISDN mu-law encoding at a sample rate of 8kHzApplication
Octet-streamPostscript Adobe Postscirpt.General binary data consisting of 8-bit bytes.
MIME (contd.)
The other major component of MIME is a definition of transfer encodings for message contents:
Encoding Description
7bit The data are all represented by short lines of ASCII chars.
8bit The lines are short, but there may be non-ASCII chars.
Binary Not only may non-ASCII chars be presented but lines are not necessarily short enough for SMTP transport.
Quoted-printable Encodes the data in such a way that if the data being encoded are mostly ASCII text, the encoded form of the data remains largely recognizable by humans.
Base64 Encodes data by mapping 6-bit blocks to 8-bit printable ASCII characters blocks.
x-token A nonstandard encoding.
MIME (contd.)
Canonical form is a format that is
standardized for use between systems.
Conclusions:
MIME is a necessity in today’s Internet and e-mail traffic requirements.
The “Object Oriented” structure of the MIME message enhances its capability to serve as multipurpose standard.
The MIME is capable of transferring data
between two distinct systems which uses different
formats
S/MIME - Functions
S/MIME is based on the Cryptographic Message Syntax (CMS) specified in RFC 2630.
Enveloped data:
This consists of encrypted content of any type and encrypted content encryption keys for one or more users. This functions provides privacy and data security.
Signed data:
A digital signature is formed by signing the message digest and then encrypting that with the signer private key. The content and the signature are then encoded using base64 encoding.
This function provides authenticity, message integrity and non- repudiation of origin.
S/MIME - Functions
SignerInfo: allows the inclusion of
unsigned and signed attributes to be included along with a signature.
signingTime
sMIMECapabilities
sMIMEEncryptionKeyPreference
S/MIME - Functions
Clear signed data:
In this case a digital signature of the content is formed, However only the signature is
encoded with base64.
Signed and enveloped data:
Because of S/MIME encapsulating capability (multipart type), signed only and encrypted
only entities may be nested, so that encrypted
data may be signed and signed data may be
encrypted.
S/MIME - Cryptography
Definitions:
MUST: The definition is an absolute requirement of the specification.
SHOULD: There may exist valid reasons in
particular circumstances to ignore this feature or function, but it is recommended that an
implementation include the feature or function.
Be liberal in what you receive and
conservative in what you send.
S/MIME - Cryptography
Function Requirement
Creation of a
message digest. MUST support SHA-1. SHOULD use sha-1.
Receiving agents SHOULD support MD5 for the purpose of providing backward compatibility with S/MIME v2.
A message digest encryption to form a digital signature.
Both sending and receiving agents MUST support DSS.
Receiving agents SHOULD support verification of RSA signatures with key sizes 512 bits to 1024 bits. Note that S/MIME v2 clients are only capable of verifying digital signatures using RSA.
S/MIME - Cryptography
Function Requirement
A session key encryption for transmission with the message.
Both sending and receiving agents MUST support Diffie-Hellman.
Sending agents SHOULD support RSA encryption with key sizes 512 to 1024 bits.
Receiving agents SHOULD support RSA decryption.
A message Encryption for transmission with one-time session key.
Sending an receiving agent MUST support Encryption/Decryption with 3DES.
Receiving agents SHOULD support decryption with RC2/40.
(S/MIME V 2. - Sending agents SHOULD support RSA encryption with 3DES and RC2/40. Receiving agents MUST
support decryption with RC2/40.)
S/MIME - Cryptography
Algorithm use decision procedure:
Preferred decrypting capabilities: SHOULD choose the first (highest preference) capability on the list.
No list of capabilities but has received message/s:
SHOULD use the same encryption algorithm as was used on the last signed and encrypted message.
No knowledge & Willing to risk:
willing to risk that the recipient may not be able to decrypt the message, then the sending agent SHOULD use 3DES.
No knowledge & Not willing to risk:
sending agent MUST use RC2/40.
S/MIME - Cryptography
A possible problem:
A multiple recipients message:
Performance
Security
The Solution:
This problem is solved using an Enhanced
Security service called S/MIME Mail List Agent (MLA).
An MLA perform the recipient-specific encryption
for each recipient, and forward the message.
S/MIME - Message
MIME bodies + CMS.
Algorithm Identifiers Canonical
MIME Certificates
CMS
CMS object
MIME
Encoding + Canonical
form
S/MIME - Message
Description S/MIME
parameter Subtype
Type
A clear message in tow parts:
One is the message and the other is the signature.
Signed Multipart
A signed S/MIE entity.
An encrypted S/MIME entity.
multipart/signed message.
A certificate registration request message.
signedData envelopedData
-- -- pkcs7-mime
pkcs7-mime Pkcs7-signature pkcs10-mime Application
S/MIME - Message
Enveloped Data:
Pseudorandom session key
(3DES or RC2/40) ׁ
ׁ
Certificate
RecipientInfo
M
enveloped-data +
Encrypt the session key Diffie-Hellman /
RSA Recipient’s public key
S/MIME - Message
M
Hash function
SHA-1 or MD5
Encryption Sender’s private key
Certificate
SignerInfo
Base64 encoding
