1. S/MIME (Secure/Multipurpose Internet Mail Extensions)
security enhancement to MIME
original Internet RFC822 was text only
MIME provided support for varying content types and multi-part messages
with encoding of binary data to textual form
S/MIME added security enhancements
have S/MIME support in many mail agents
eg MS Outlook, Mozilla, Mac Mail etc
S/MIME (Secure/Multipurpose Internet Mail Extension) is a security enhancement to the MIME Internet format standard, which in turn provided support for varying content types and multi-part messages over the text only support in the original Internet RFC822 (now RFC5322) standard. See text for discussion of these extensions. MIME is specified in RFCs 2045 through MIME allows encoding of binary data to textual form for transport over traditional RFC822 systems. S/MIME support is now included in many modern mail agents.

2. S/MIME Functions enveloped data signed data clear-signed data
encrypted content and associated keys
signed data
encoded message + signed digest
clear-signed data
cleartext message + encoded signed digest
signed & enveloped data
nesting of signed & encrypted entities
In terms of general functionality, S/MIME is very similar to PGP. Both offer the ability to sign and/or encrypt messages. S/MIME provides the functions shown.

3. S/MIME Cryptographic Algorithms
digital signatures: DSS & RSA
hash functions: SHA-1 & MD5
session key encryption: ElGamal & RSA
message encryption: AES, Triple-DES, RC2/40 and others
MAC: HMAC with SHA-1
have process to decide which algs to use
S/MIME uses a range of cryptographic algorithms, as shown. Support for SHA-1, DSS, RSA and Triple-DES is required, the rest should be provided for backwards compatibility of possible.
The S/MIME specification includes a discussion of the procedure for deciding which content encryption algorithm to use, based on the capabilities of all parties. To support this decision process, a sending agent may announce its decrypting capabilities in order of preference any message that it sends out. A receiving agent may store that information for future use. If a message is to be sent to multiple recipients and a common encryption algorithm cannot be selected for all, then the sending agent will need to send two messages. However, in that case, it is important to note that the security of the message is made vulnerable by the transmission of one copy with lower security.

4. S/MIME Cryptographic Algorithms
Must: The definition is an absolute requirement of the specification. An implementation must include this feature or function to be in conformance with 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.
The following rules, in the following order, should be followed by a sending agent:
1. If the sending agent has a list of preferred decrypting capabilities from an intended recipient, it SHOULD choose the first (highest preference) capability on the list that it is capable of using.
2.If the sending agent has no such list of capabilities from an intended recipient but has received one or more messages from the recipient, then the outgoing message SHOULD use the same encryption algorithm as was used on the last signed and encrypted message received from that intended recipient.

5. S/MIME Cryptographic Algorithms
3. If the sending agent has no knowledge about the decryption capabilities of the intended recipient and is willing to risk that the recipient may not be able to decrypt the message, then the sending agent SHOULD use tripleDES. 4. If the sending agent has no knowledge about the decryption capabilities of the intended recipient and is not willing to risk that the recipient may not be able to decrypt the message, then the sending agent MUST use RC2/ If a message is to be sent to multiple recipients and a common encryption algorithm cannot be selected for all, then the sending agent will need to send two messages. However, in that case, it is important to note that the security of the message is made vulnerable by the transmission of one copy with lower security.

6. S/MIME Messages
S/MIME secures a MIME entity with a signature, encryption, or both
forming a MIME wrapped PKCS object
have a range of content-types:
enveloped data
signed data
clear-signed data
registration request
certificate only message
S/MIME secures a MIME entity with a signature, encryption, or both. A MIME entity may be an entire message or one or more of the subparts of the message. The MIME entity plus some security related data, such as algorithm identifiers and certificates, are processed by S/MIME to produce a PKCS, which refers to a set of public-key cryptography specifications issued by RSA Laboratories. A PKCS object is then treated as message content and wrapped in MIME. A range of S/MIME content-types are specified, as shown. See text for details of how these are used.

7. S/MIME Messages Enveloped Data
The steps for preparing an enveloped Data MIME entity are as follows:
1. Generate a pseudorandom session key for a particular symmetric encryption algorithm (RC2/40 or tripleDES).
2. For each recipient, encrypt the session key with the recipient's public RSA key.
3.For each recipient, prepare a block known as Recipient Info that contains an identifier of the recipient's public-key certificate, an identifier of the algorithm used to encrypt the session key, and the encrypted session key.
4. Encrypt the message content with the session key.

8. S/MIME Messages SignedData
The signedData smime-type can actually be used with one or more signers. For clarity, we confine our description to the case of a single digital signature.
The steps for preparing a signedData MIME entity are as follows:
1. Select a message digest algorithm (SHA or MD5).
2. Compute the message digest, or hash function, of the content to be signed.
3. Encrypt the message digest with the signer's private key.
4. Prepare a block known as SignerInfo that contains the signer's public-key certificate, an identifier of the message digest algorithm, an identifier of the algorithm used to encrypt the message digest, and the encrypted message digest.

9. S/MIME Messages Clear Signing
Clear signing is achieved using the multipart content type with a signed subtype. As was mentioned, this signing process does not involve transforming the message to be signed, so that the message is sent "in the clear." Thus, recipients with MIME capability but not S/MIME capability are able to read the incoming message.
A multipart/signed message has two parts.
The first part can be any MIME type but must be prepared so that it will not be altered during transfer from source to destination. This means that if the first part is not 7bit, then it needs to be encoded using base64 or quoted-printable. Then this part is processed in the same manner as signedData, but in this case an object with signedData format is created that has an empty message content field.
This object is a detached signature. It is then transfer encoded using base64 to become the second part of the multipart/signed message.
This second part has a MIME content type of application and a subtype of pkcs7-signature.

10. S/MIME Messages Registration Request
Typically, an application or user will apply to a certification authority for a public-key certificate. The application/pkcs10 S/MIME entity is used to transfer a certification request.
The certification request includes certificationRequestInfo block, followed by an identifier of the public-key encryption algorithm, followed by the signature of the certificationRequestInfo block, made using the sender's private key.
The certificationRequestInfo block includes a name of the certificate subject (the entity whose public key is to be certified) and a bit-string representation of the user's public key.

11. S/MIME Messages Certificates-Only Message
A message containing only certificates or a certificate revocation list (CRL) can be sent in response to a registration request.
The message is an application/pkcs7-mime type/subtype with an smime-type parameter of degenerate.
The steps involved are the same as those for creating a signedData message, except that there is no message content and the signerInfo field is empty.

12. S/MIME Certificate Processing
S/MIME uses X.509 v3 certificates
managed using a hybrid of a strict X.509 CA hierarchy & PGP’s web of trust
each client has a list of trusted CA’s certs and own public/private key pairs & certs
certificates must be signed by trusted CA’s
S/MIME uses public-key certificates that conform to version 3 of X.509 (see Chapter 14). The key-management scheme used by S/MIME is in some ways a hybrid between a strict X.509 certification hierarchy and PGP’s web of trust. S/MIME managers and/or users must configure each client with a list of trusted keys and with certificate revocation lists, needed to verify incoming signatures and to encrypt outgoing messages. But certificates are signed by trusted certification authorities.

13. S/MIME Certificate Processing
User Agent Role
An S/MIME user has several key-management functions to perform:
Key generation: The user of some related administrative utility (e.g., one associated with LAN management) MUST be capable of generating separate Diffie-Hellman and DSS key pairs and SHOULD be capable of generating RSA key pairs.
Each key pair MUST be generated from a good source of nondeterministic random input and be protected in a secure fashion. A user agent SHOULD generate RSA key pairs with a length in the range of 768 to 1024 bits and MUST NOT generate a length of less than 512 bits.
Registration: A user's public key must be registered with a certification authority in order to receive an X.509 public-key certificate.
Certificate storage and retrieval: A user requires access to a local list of certificates in order to verify incoming signatures and to encrypt outgoing messages. Such a list could be maintained by the user or by some local administrative entity on behalf of a number of users.

14. Certificate Authorities
have several well-known CA’s
Verisign one of most widely used
Verisign issues several types of Digital IDs
increasing levels of checks & hence trust
Class Identity Checks Usage
1 name/ check web browsing/
2 + enroll/addr check , subs, s/w validate
3 + ID documents e-banking/service access
There are several companies that provide X.509 certification authority (CA) services. Of these, the most widely used is the VeriSign CA service. VeriSign issues X.509 certificates known as Digital IDs. As of early 1998, over 35,000 commercial Web sites were using VeriSign Server Digital IDs, and over a million consumer Digital IDs had been issued to users of Netscape and Microsoft browsers. VeriSign provides three levels, or classes, of security for public-key certificates, with increasing levels of checks & hence trust, as shown above, and with additional details in Stallings Table Class 1 and Class 2 requests are processed on line, and in most cases take only a few seconds to approve. For Class 3 Digital IDs, VeriSign requires a higher level of identity assurance. An individual must prove his or her identity by providing notarized credentials or applying in person.

15. Certificate Authorities
VeriSign Certificates
The information contained in a Digital ID depends on the type of Digital ID and its use. At a minimum, each Digital ID contains
Owner's public key
Owner's name or alias
Expiration date of the Digital ID
Serial number of the Digital ID
Name of the certification authority that issued the Digital ID
Digital signature of the certification authority that issued the Digital ID
Digital IDs can also contain other user-supplied information, including
Address
address
Basic registration information (country, zip code, age, and gender)

16. Certificate Authorities
For Class 1 Digital IDs, VeriSign confirms the user's address by sending a PIN and Digital ID pick-up information to the address provided in the application.
For Class 2 Digital IDs, VeriSign verifies the information in the application through an automated comparison with a consumer database in addition to performing all of the checking associated with a Class 1 Digital ID. Finally, confirmation is sent to the specified postal address alerting the user that a Digital ID has been issued in his or her name.
For Class 3 Digital IDs, VeriSign requires a higher level of identity assurance. An individual must prove his or her identity by providing notarized credentials or applying in person.

17. S/MIME Enhanced Security Services
3 proposed enhanced security services:
signed receipts:
recipient sends a signed msg.
security labels:
Included in authenticated attributes.
used access ctrl, priority, role based.
secure mailing lists:
S/MIME Mail List Agent(MLA) – perform the recipient specific encryption for each recipient and fwd the message.
As of this writing, three enhanced security services have been proposed in an Internet draft, and may change or be extended. The three services are:
• Signed receipts: may be requested in a SignedData object to provide proof of delivery to the originator of a message and allows the originator to demonstrate to a third party that the recipient received the message.
• Security labels: may be included in the authenticated attributes of a SignedData object, and is a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation. They may be used for access control, indicating which users are permitted access to an object
• Secure mailing lists: When a user sends a message to multiple recipients, a certain amount of per-recipient processing is required, including the use of each recipient's public key. The user can be relieved of this work by employing the services of an S/MIME Mail List Agent (MLA). An MLA can take a single incoming message, perform recipient-specific encryption for each recipient, and forward the message. The originator of a message need only send the message to the MLA, with encryption performed using the MLA's public key.

18. Secure Hash Algorithm SHA originally designed by NIST & NSA in 1993
was revised in 1995 as SHA-1
US standard for use with DSA signature scheme
standard is FIPS , also Internet RFC3174
nb. the algorithm is SHA, the standard is SHS
based on design of MD4 with key differences
produces 160-bit hash values
recent 2005 results on security of SHA-1 have raised concerns on its use in future applications
The Secure Hash Algorithm (SHA) was developed by the National Institute of Standards and Technology (NIST) and published as a federal information processing standard (FIPS 180) in 1993; a revised version was issued as FIPS in 1995 and is generally referred to as SHA-1. The actual standards document is entitled Secure Hash Standard. SHA is based on the hash function MD4 and its design closely models MD4. SHA-1 produces a hash value of 160 bits. In 2005, a research team described an attack in which two separate messages could be found that deliver the same SHA-1 hash using 2^69 operations, far fewer than the 2^80 operations previously thought needed to find a collision with an SHA-1 hash [WANG05]. This result should hasten the transition to newer, longer versions of SHA.

19. Revised Secure Hash Standard
NIST issued revision FIPS in 2002
adds 3 additional versions of SHA
SHA-256, SHA-384, SHA-512
designed for compatibility with increased security provided by the AES cipher
structure & detail is similar to SHA-1
hence analysis should be similar
but security levels are rather higher
In 2002, NIST produced a revised version of the standard, FIPS 180-2, that defined three new versions of SHA, with hash value lengths of 256, 384, and 512 bits, known as SHA-256, SHA-384, and SHA-512. These new versions have the same underlying structure and use the same types of modular arithmetic and logical binary operations as SHA-1, hence analyses should be similar. In 2005, NIST announced the intention to phase out approval of SHA-1 and move to a reliance on the other SHA versions by See Stallings Table12.1 for comparative details of these algorithms.

20. SHA - 512

21. SHA-512 Overview
Now examine the structure of SHA-512, noting that the other versions are quite similar.
SHA-512 follows the structure depicted in Stallings Figure The processing consists of the following steps:
• Step 1: Append padding bits
• Step 2: Append length
• Step 3: Initialize hash buffer
• Step 4: Process the message in 1024-bit (128-word) blocks, which forms the heart of the algorithm
• Step 5: Output the final state value as the resulting hash
See text for details.

22. SHA - 512
Step 1: Append padding bits. The message is padded so that its length is congruent to 896 modulo 1024 [length 896 (mod 1024)]. Padding is always added, even if the message is already of the desired length. Thus, the number of padding bits is in the range of 1 to The padding consists of a single 1-bit followed by the necessary number of 0-bits. Step 2: Append length. A block of 128 bits is appended to the message. This block is treated as an unsigned 128-bit integer (most significant byte first) and contains the length of the original message (before the padding). The outcome of the first two steps yields a message that is an integer multiple of 1024 bits in length. The expanded message is represented as the sequence of 1024-bit blocks M1, M2,..., MN, so that the total length of the expanded message is N x 1024 bits. Step 3: Initialize hash buffer. A 512-bit buffer is used to hold intermediate and final results of the hash function. The buffer can be represented as eight 64-bit registers (a, b, c, d, e, f, g, h). These registers are initialized to the following 64-bit integers (hexadecimal values):

23. SHA - 512 a = 6A09E667F3BCC908 b = BB67AE8584CAA73B
c = 3C6EF372FE94F82B d = A54FF53A5F1D36F1
e = 510E527FADE682D f = 9B05688C2B3E6C1F
g = 1F83D9ABFB41BD6B h = 5BE0CDI9137E2179
These values are stored in big-endian format, which is the most significant byte of a word in the low-address (leftmost) byte position. These words were obtained by taking the first sixty-four bits of the fractional parts of the square roots of the first eight prime numbers.
Step 4: Process Message in 1024-bit (128 word) blocks:
The heart of the algorithm is a module that consists of 80 rounds; this module is labeled F.

24. SHA – 512 Processing of a Single 1024 – Bit Block

25. SHA – 512 H0 = IV Hi = SUM64(Hi-1, abcdefghi) MD = HN
Step 5: Output. After all N 1024-bit blocks have been processed, the output from the Nth stage is the 512-bit message digest.
We can summarize the behavior of SHA-512 as follows:
H0 = IV
Hi = SUM64(Hi-1, abcdefghi)
MD = HN
where
IV = initial value of the abcdefgh buffer, defined in step 3
abcdefghi = the output of the last round of processing of the i th message block
N = the number of blocks in the message (including padding and length fields)
SUM64 = Addition modulo performed separately on each word of the pair of inputs
MD = final message digest value

26. SHA-512 Compression Function
heart of the algorithm
processing message in 1024-bit blocks
consists of 80 rounds
updating a 512-bit buffer
using a 64-bit value Wt derived from the current message block
and a round constant based on cube root of first 80 prime numbers
The SHA-512 Compression Function is the heart of the algorithm. In this Step 4, it processes the message in 1024-bit (128-word) blocks, using a module that consists of 80 rounds, labeled F in Stallings Figure 12, as shown in Figure Each round takes as input the 512-bit buffer value, and updates the contents of the buffer. Each round t makes use of a 64-bit value Wt derived using a message schedule from the current 1024-bit block being processed. Each round also makes use of an additive constant Kt, based on the fractional parts of the cube roots of the first eighty prime numbers. The output of the eightieth round is added to the input to the first round to produce the final hash value for this message block, which forms the input to the next iteration of this compression function, as shown on the previous slide.

27. SHA-512 Round Function
The structure of each of the 80 rounds is shown in Stallings Figure Each 64-bit word shuffled along one place, and in some cases manipulated using a series of simple logical functions (ANDs, NOTs, ORs, XORs, ROTates), in order to provide the avalanche & completeness properties of the hash function. The elements are:
Ch(e,f,g) = (e AND f) XOR (NOT e AND g)
Maj(a,b,c) = (a AND b) XOR (a AND c) XOR (b AND c)
∑(a) = ROTR(a,28) XOR ROTR(a,34) XOR ROTR(a,39)
∑(e) = ROTR(e,14) XOR ROTR(e,18) XOR ROTR(e,41)
+ = addition modulo 2^64
Kt = a 64-bit additive constant
Wt = a 64-bit word derived from the current 512-bit input block.

28. SHA-512 Round Function
Stallings Figure 12.4 details how the 64-bit word values Wt are derived from the 1024-bit message. The first 16 values of Wt are taken directly from the 16 words of the current block. The remaining values are defined as a function of the earlier values using ROTates, SHIFTs and XORs as shown. The function elements are:
∂0(x) = ROTR(x,1) XOR ROTR(x,8) XOR SHR(x,7)
∂1(x) = ROTR(x,19) XOR ROTR(x,61) XOR SHR(x,6).

29. Hash Functions
A cryptographic hash Function h takes as input a message of arbitrary length and produces as output a message digest of fixed length; for example, 160 bits as depicted in Figure 8.1. Certain properties should be satisfied:

30. Hash Functions
1. Given a message m, the message digest h(m) can be calculated very quickly.
2. Given a y, it is computationally infeasible to find an m' with h(m') = y (in other words, A is a one-way, or preimage resistant function). Note that if y is the message digest of some message, we are not trying to find this message. We are only looking for some m' with h(m’) = y.
It is computationally infeasible to find messages m1 and m2 with h(m1) = h(m2) (in this case, the function h is said to be strongly collision-free).
One of the main uses of hash functions is in digital signatures. Since the length of a digital signature is often at least as long as the document being signed, it is much more efficient to sign the hash of a document rather the the full document.

31. Hash Functions
Hash functions may also be employed as a check on data integrity.
The question of data integrity comes up in basically two scenarios.
The first is when the data (encrypted or not) are being transmitted to another person and a noisy communication channel introduces errors to the data.
The second occurs when an observer rearranges the transmission in some manner before it gets to the receiver. Either way, the data have become corrupted.
For example, suppose Alice sends Bob long messages about financial transactions with Eve and encrypts them in blocks. Perhaps Eve deduces that the tenth block of each message lists the amount of money that is to be deposited to Eve’s account. She could easily substitute the tenth block from one message into another and increase the deposit.

32. Hash Functions
In another situation, Alice might send Bob a message consisting of several blocks of data, but one of the blocks is lost during transmission. Bob might not ever realize that the block is missing.
Here is how hash functions can be used. Say we send (m, h(m)) over the communications channel and it is received as (M ,H ). To check whether errors might have occurred, the recipient computes h(M) and sees whether it equals H. If any errors occurred, it is likely that h(M)!= H, because of the collision-free properties of h.

33. Birthday Attacks
If there are 23 people in a room, the probability is slightly more than 50% that two of them have the same birthday. If there are 30, the probability is around 70%. This might seem surprising; it is called the birthday paradox.
Let’s see why it's true. We'll ignore leap years and assume that all birthdays are equally likely (if not, the probabilities given would be slightly higher).
Consider the case of 23 people. We’ll compute the probability that they all have different birthdays. Line them up in a row. The first person uses up one day, so the second person has probability (1 — 1/365) of having a different birthday. There are two days removed for the third person, so the probability is (1 — 2/365) that the third birthday differs from the first two.

34. Birthday Attacks
Therefore, the probability of all three people having different birthdays is (1 — 1/365)(1 — 2/365). Continuing in this way, we see that the probability that all 23 people have different birthdays is
Therefore, the probability of at least two having the same birthday is
= .507
One way to understand the preceding calculation intuitively is to consider the case of 40 people. If the first 30 have a match, we're done, so suppose the first 30 have different birthdays.
Now we have to choose the last 10 birthdays. Since 30 birthdays are already chosen, we have approximately a 10% chance that a randomly chosen birthday will match one of the first 30. And we are choosing 10 birthdays.
Therefore, it shouldn’t be too surprising that we get a match. In fact, the probability is 89% that there is a match among 40 people.

35. Birthday Attacks
More generally, suppose we have N objects, where N is large. There are r people, and each chooses an object (with replacement, so several people could choose the same one). Then
Note that this is only an approximation that holds for large N ; for small n it Is better to use the above product and obtain an exact answer. In Exercise 6, we derive this approximation. Choosing r2 / 2N = In2, we find that if r=1.177 √N, then the probability is 50% that at least two people choose the same object.
To summarize, if there are N possibilities and we have a list of length √N, then there is a good chance of a match. If we want to increase the chance of a match, we can make the list have length 2 √N or 5 √N. The main point is that a length of a constant times √N (instead of something like N) suffices.

36. Birthday Attacks
For example, suppose we have 40 license plates, each ending in a 3-digit number. What is the probability that two of the license plates end in the same 3 digits? We have N = 1000, the number of possible 3-digit numbers, and r = 40, the number of license plates under consideration. Since
the approximate probability of a match is
which is more than 50%. We stress that this is only an approximation. The correct answer is obtained by calculating