CS 772 - Network & Systems Security-Fall 2012
General Concepts
Introduction to Cryptography
Introduction to OpenSSL
Message Digests
Public Key Cryptography
Secret Key Cryptography
Base64 Encode/Decode
Secret Key Cryptography
General Block Encryption
Data Encryption Standard (DES)
International Data Encryption Algorithm (IDEA)
Advanced Encryption Standard (AES)
Stream Cipher RC4
Block Chaining
Electronic Code Book (ECB)
Cipher Block Chaining (CBC)
Output Feedback Mode (OFB)
Cipher Feedback Mode (CFB)
Counter Mode (CTR)
Multiple Encryption DES
Hashes and Message Digests
Major Algorithms
Things to do with Hash
MD 2 Algorithm
Public Key Cryptography
Modular Arithmetic
RSA
Diffie-Hellman
ElGammal Signatures
Zero-Knowledge Proofs
Number Theory
Prime Numbers
Euclid’s Algorithm
The Chinese Remainder Theorem
Euler’s Theorem
Public Key Infrastructure (PKI) Certificates
Certificate Requests Commands
Certificate Authority Commands
Application of PKI: Secure MIME
Email Security: PEM & S/MIME
Real-Time Communication Security: SSL, https
SSL programming
SSL Client
SSL Server
Common functions
Generating pem files
Introduction to Authentication Systems
Security Handshake Protocols
Network Authentication Standards: Kerberos
General Concepts
Players:
Alice, Bob & Trudy.
How to communicate securely over an insecure medium?
Alice should be able to send a message to Bob that
Trudy can't understand or modify
and Bob is assured that Alice is the sender.
Passive Attacks:
The attacker eavesdrops and read/record messages in transit.
Active Attacks:
The attacker may transmit new messages, replay old messages,
modify/delete messages on transit.
Layers and Cryptography:
Application (e.g., PEM),
Transport (e.g., SSL),
Network (e.g., IPsec).
Authentication:
Who are you?
Authorization:
Should you be doing that?
ACL (access control list) & Groups.
Trojan horse/virus/worm:
Malicious code written by bad guys.
Modern mail systems & Internet connectivity (Cable Modems/DSL)
contribute to its spread.
Virus Checkers: looks for instruction sequences for known viruses
and uses message digests for files.
Security Levels:
Unclassified < Confidential < Secret < Top Secret
Mandatory Access Control Rules:
No read-up (read higher rating object).
No write-down (write an object with lower rating).
Covert Channels :
Very low bandwidth (e.g., 1 bit every 10 seconds),
but can be used to steal cryptographic keys.
E.g., a Trojan horse may use timing channel or storage channel
Loops 1 minute if a bit is 1 and waits 1 minute if a bit is 0.
Creates a file for 1 minute if a bit is 1 and deletes the file for 2
minute if a bit is 0.
Steganography:
Hide secret messages in other messages.
E.g., hide messages in images by replacing the least significant bit of
each byte of the image with the bits of the message.
DEMO: /home/cs772/public_html/demos/steganography
The Orange Book:
Rates computer systems (D, C1,C2, B1,B2,B3 and A1). E.g.,
> C1 classical time-sharing system like Unix (use login/password and access
control (owner/group/world) to protect files.
> C2 is C1 + access control per user granularity, clearing allocated memory
file space, and audit trails.
> B1 is C2 + use security labels for users/processes/files and prevent read-up
and write-down, printers attach label to each printed page.
Patents & Export Control:
Luckily most patents have expired (e.g. RSA Sept 20, 2000),
and recently most export control has been lifted.
The US considered encryption as danger as the weapons of mass
destruction, like nuclear and biological technology.
Introduction To Cryptography
Traditional use of cryptography:
plaintext >>>>>>>>>> ciphertext >>>>>>>>> plaintext
(encryption)
(decryption)
• cryptographer: invent clever secret codes.
• cryptanalyst: attempt to break these codes.
Fundamental Tenet of Cryptography:
If lots of smart people failed to solve a problem, then it probably won't be solved
(soon).
• The time required to break a code should be longer than the time the
encrypted data must remain secret.
• The value of most data decreases overtime.
Cryptographic System: Algorithm + Key
It is perfectly OK to let everyone know the algorithm because knowledge
of the algorithm without the key does not help unmingled the
information.
Publishing the algorithm provides an enormous amount of free consulting
to uncover weaknesses.
Computational Difficulty:
Example: combination lock
• Typically require 3 numbers between 1 and 40.
If it takes 10 seconds for a good guy,
it would take 10*(40**3) seconds or about 1 week for the bad guy.
• By requiring 4 numbers,
If it takes 13 seconds for the good guy,
it would take 13*(40**4) seconds or about 1 year for the bad guy!
In general, increasing the key length by 1 bit makes the good guy's job
just a little bit harder, but makes the bad guy's job twice as hard!
Example of Secret Codes:
Caesar cipher:
Substitute each letter with another letter which is 3 letters away in
the alphabet (with wrap around).
E.g., dozen >>> grchq.
Extension: Instead of 3 use any number n between 1 and 25.
E.g., for n=1, HAL >>> IBM.
Monoalphabetic cipher:
Arbitrary map one letter to another.
There are 26!=4*(10**26) possibilities.
If each possibility takes 1 microsecond it would take 10 trillion years
to try all possibilities.
However statistical analysis of language makes it much easier to
break:
Examples
The Homophonic Substitution cipher:
Replacing each letter with a variety of substitutes, the number of
potential substitutes being proportional to the frequency of the letter.
Examples
Breaking An Encryption Scheme
Ciphertext Only: Because it is important for Trudy to be able to
differentiate plaintext from gibberish, this attack sometime known as
recognizable plaintext attack.
It is also essential for Trudy to have enough ciphertext, e.g., there is no
way to know the plaintext corresponding to XYZ is THE or CAT or
HAT.
Known Plaintext: Knowing <plaintext, ciphertext> pairs are helpful for
Trudy,
e.g., in monoalphabetic cipher Trudy learns the mapping.
How to obtain plaintext? Secret data might not remain secret forever,
e.g., which city to attack might not be secret after that attack!
Chosen Plaintext: Trudy can choose any plaintext he wants and get the
system to provide corresponding ciphertext, e.g., telegraph company can
encrypt and send any message you provide.
Example: If Trudy knows that Alice encrypted message (azsxopfq) is
either (surrender) or (fight on), he can ask the system to encrypt both
messages and find out the correct one.
Types of Cryptographic Functions:
Secret Key Cryptography (symmetric cryptography)
(encryption)
plaintext >>>>>>>>> ciphertext
|
key
|
ciphertext >>>>>>>> plaintext
(decryption)
Can be used for:
•
•
Transmission Over an Insecure Channel:
An eavesdropper will only see unintelligible data.
Secure Storage on Insecure Media:
Forgetting the key makes the data irrevocably lost.
•
Authentication: Alice authenticating Bob:
Alice
challenge:
r
Bob
>>>>>>>
r
response:
<<<<<<<
K{r}
K{r}
r
is a random number,
K{r} is the secret key encryption of r using shared key K.
Public Key Cryptography (asymmetric cryptography)
Each individual has two keys:
private key (not revealed to anyone)
public key (make it known to everyone)
(encryption)
plaintext >>>>>>>>>> ciphertext
|
public key
private key
|
ciphertext >>>>>>>>> plaintext
(decryption)
The reverse process is called digital signature:
(signing)
plaintext >>>>>>>>> ciphertext
|
private key
public key
|
ciphertext >>>>>>>> plaintext
(verification)
Public key cryptographic algorithms are orders of magnitude slower than
the best known secret key cryptographic algorithms. Thus they normally
used to establish temporary shared secret key for use during a session.
Uses of Public Key Cryptography:
Transmission Over an Insecure Channel:
Alice
{K}eB
K{mB}
K{mA}
Bob
>>>>>>>>>
>>>>>>>>>
<<<<<<<<<
[K]dB
K{mB}
K{mA}
K is a random session key.
<eB, dB> is the <public-key , private-key> pair for Bob.
{m}eB is the public key encryption of message m with eB.
[m]dB is the public key decryption of message m with dB.
K{m} is the symmetric key encryption of message m with K.
mB message for Bob.
mA message for Alice.
Secure Storage on Insecure Media:
Alice generates a random key K and save:
F= K{File}
KF= {K}eA
To restore the file:
K= [KF]dA
File = K{F}
Authentication: Alice authenticating Bob:
challenge:
Alice
c = { r }eB
>>>>>
response:
r
<<<<<
r
is a random number
Bob
c
r = [c]dB
Hash Algorithms
(also known as: message digest, fingerprint, one-way functions )
The hash of a message m, h=H(m) has the following properties:
• Given m, it is easy to compute h.
• Given h, it is hard to compute m.
• Given m, it is hard to find another m' such that H(m) = H(m').
• It is hard to find m1 and m2 such that H(m1) = H(m2).
Uses of Hash Algorithms:
MAC/MIC (Message Authentication/Integrity Code)
Using Secret Key:
Alice
Bob
m,h where h = H(m|K) >>>>>
m,h , OK if h = H (m|K)
K is the shared secret between Alice and Bob
Note that:
• Bob is sure that Alice sent the message, since she knows K.
• Bob can NOT prove to any one that Alice sent him message m, since
he also knows K.
Using Public Key:
Alice
Bob
m,sh where sh = [H(m)]dA >> m,sh , OK if H (m) = {sh}eA
<eA, dA> is the public/private key pair of Alice
Note That:
• Bob is sure that Alice sent the message, since she knows dA.
• He can also prove to any one that Alice sent him message m, since
he does not know dA.
This property of public key cryptography is known as non-repudiation,
where the sender should not be able to falsely deny that he sent a
message.
Password Hashing:
OS like UNIX stores the hash of passwords instead of storing the actual
passwords.
• For each user U, there is a tuple <U, h>
where h = H(P) is the hash of password P of user U.
• When a user U types a password, P, the OS compute H(P) and
if it is equal to the saved value h in the tuple <U,h>, the user is OK.
The magic of XOR: A Simple symmetric algorithm:
(from Bruce Shneier textbook)
0®0=0
0®1=1
1®0=1
1®1=0
Note that:
x ® x =0
x ® 0 =x
The following program is a very simple symmetric algorithm.
(see /home/cs772/public_html/demos/xor )
• To encrypt: the plaintext P is XORed with a key K to produce a
ciphertext C.
• To decrypt: the ciphertext C is XORed with a key K to produce a
plaintext P.
P®K= C
C®K= P
Why?
Since C ® K = (P ® K) ® K = P ® (K ® K) = P ® 0 = P
This is a very insecure algorithm that can be easily broken.
It is good enough to keep "your kid sister" from reading your files!
crypto
Usage:
% crypto
<key>
<input_file>
<output_file>
Example:
To encrypt infile:
% crypto "odu computer science" infile outfile
To decrypt outfile:
% crypto "odu computer science" outfile tmpfile
tmpfile is identical to infile
Code:
void main (int argc, char *argv[])
{
FILE *fi, *fo;
char *cp;
int c;
if ((cp = argv[1]) && *cp!='\0') {
if ((fi = fopen(argv[2], “rb”)) != NULL) {
if ((fo = fopen(argv[3], “wb”)) !=
NULL) {
while ((c = getc(fi)) != EOF) {
if (!*cp) cp = argv[1];
c ^= *(cp++);
putc(c,fo);
}
fclose(fo);
}
fclose(fi);
}
}
}
OpenSSL – Introduction
OpenSSL documentation (man openssl) - ( openssl.pdf )
NOTE: For most openssl commands you should first do the following:
% cp /home/cs772/randomfile .
% setenv
RANDFILE
randomfile
Message Digest
( man dgst )
% more file1.txt
Hussein Wahab
Old Dominion University
% openssl
dgst
-sha1
file1.txt
SHA1(file.txt)= 439d855153b88dff064af44cc7794026bad31a45
% more file2.txt
hussein Wahab
Old Dominion University
% openssl dgst -sha1 file2.txt
SHA1(file.txt)= 3204dcbee726eb0319b3094f3947539b5e15c969
% diff file1.txt file2.txt
1c1
< Hussein Wahab
--> hussein Wahab
Thus small difference (H vs. h) completely changes the digest.
To record the digest of a file us:
% openssl dgst -sha1 -out digest_file1.txt file1.txt
% cat digest_file1.txt
SHA1(file1.txt)= 439d855153b88dff064af44cc7794026bad31a45
Or you can use:
% openssl dgst -sha1 file1.txt > digest_file1.txt
Public Key Cryptography (Asymmetric)
(man genrsa ) & ( man rsa )
Generating RSA keys
% openssl genrsa -out rsaprivatekey.pem -des3 1024
This generate the private key and store it encrypted (using password)
Generating RSA private key, 1024 bit long modulus
e is 65537 (0x10001)
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
% openssl rsa -in rsaprivatekey.pem -pubout -out
rsapublickey.pem
This generate the corresponding public key if the correct password is provided.
read RSA key
Enter PEM pass phrase:
writing RSA key
Message Encryption/Decryption with RSA
(man rsautl)
% openssl rsautl -encrypt -pubin -inkey rsapublickey.pem -in
msg1.txt -out sg1.cipher
% openssl rsautl -decrypt -inkey rsaprivatekey.pem -in
msg1.cipher -out msg1.txt
Enter PEM pass phrase:
NOTE: msg1.txt has to be small (<=1024 bits or 128 bytes, the length of the RSA key),
since you are encrypting/decryption the file itself, not its digest.
Message Signature/Verification with RSA
% openssl rsautl -sign -inkey rsaprivatekey.pem -in msg2.txt out msg2.cipher
% openssl rsautl -verify -pubin -inkey rsapublickey.pem -out
msg2.txt -in msg2.cipher
NOTE: msg2.txt has to be small, since you are encrypting/decryption the file itself.
Signining/Verifying message digest with RSA
% openssl dgst
-sha1
-sign rsaprivatekey.pem
-out mdrsasign_file1.cipher
Enter PEM pass phrase:
file1.txt
% openssl dgst -sha1 -verify rsapublickey.pem
-signature mdrsasign_file1.cipher
file1.txt
Verified OK
Change one char in file1.txt
% openssl dgst -sha1 -verify rsapublickey.pem
-signature mdrsasign_file1.cipher file1.txt
Verification Failure
NOTE: file1.txt can be as large as you like, since you are signing the digest.
Secret Key Cryptography (Symmetric)
( man enc)
Encrypt (-e):
% openssl enc -des3 -e -salt -a -in file1.txt -out
file1cipher.base64
enter des-ede3-cbc encryption password:
Verifying password - enter des-ede3-cbc encryption password:
Decrypt (-d):
% openssl enc -des3 -d -salt -a -out file1.txt -in
file1cipher.base64
enter des-ede3-cbc decryption password:
Base64 Encode/Decode
To encode file1cipher to file1cipher.base64:
% openssl enc -base64 -e -out file1cipher.base64 -in
file1cipher
To decode file1cipher.base64 to file1cipher:
% openssl enc -base64 -d -in file1cipher.base64 -out
file1cipher
Secret Key Cryptography
General Block Encryption:
The general way of encrypting a 64-bit block is to take each of the:
264 input values and map it to a unique one of the 264 output values.
This would take (264 )*(64) = 270 bits to store this map.
This is NOT practical.
Secret key cryptographic systems take a reasonable length key
(e.g., 64 bits) and generate a one-one mapping that looks,
to someone who does not know the key, completely random.
I.e., any single bit change in the input results in
a totally independent random number output.
Types of transformation for k-bit blocks:
Substitution:
For small values of k, specify for each of the
2k possible values of the input, the k-bit output.
This takes k*2k bits.
E.g., for k=8, we need 2048 bits.
Permutation:
For each of the I input bits,
specify the output position to which it goes.
This takes I*log2 I bits.
E.g., for I=64, we need 64*6=384 bits
Rounds:
If we do only a single round,
then a bit of input can only affect 8 bits of output.
There is optimal number of rounds to achieve complete randomization,
e.g., 16.
The following figure (Fig. 3-1) shows a secret key algorithm based on rounds
of substations and permutation. It takes the same effort to reverse (decrypt).
Data Encryption Standard (DES):
Key length: 64 bits
8 bits are used for parity check,
why is that?
to make it 265 times less secure!
Read why 56 bits? section in the textbook 
How secure is DES?
In 1998, $150K machine can break the key in 5 days!
For added security triple DES is used.
Basic Structure of DES: (Fig. 3-2)
The decryption works by essentially running DES backward
with keys in reverse order: K16 .. K1.
The Permutation of Data (Fig. 3-3 )
This is not random,
See Fig. 3-3 to get IP, and
Reverse the arrows to get IP-1
In the IP table:
bit 1 comes from bit 58,
bit 2 comes from bit 50, etc.
The first octet of the input (ABC....H) is distributed over the 8 octets of the output:
A to 5th octet,
B to 1st Octet, ...
H to 4th octet.
Generating the Per-Round Keys:
Key-Permutation: (Fig. 3-4) Produces C0 and D0
C0
D0
Key-Generation: (Fig. 3-5)
Eight bits are discarded at positions:
9, 18, 22, 25 from Ci & 35, 38, 43, 54 from Di
so that each Ki is 48 bits.
A DES Round: (Fig. 3-6)
Why decryption works?
The output of the Mangler Function (M)
is the same for both encryption and decryption.
In encryption: M ® Ln = Rn+1
In decryption: M ® Rn+1 = M ® ( M ® Ln ) = Ln
The Mangler Function:
Expands R from 32 bit  48 bits as shown in Fig3-7:
It breaks R into eight 4-bit chunks and
Expand each to 6-bit by concatenating the adjacent 2 bits.
Let CRi refer to ith chunk of the expanded R.
The 48-bit K is broken to eight 6-bit chunks.
Let CKi refer to the ith chunk of K.
Let Si = CRi ® CKi
Si is fed into an S-box, a substitution which produces
4-bit output for each possible 6-bit input (Figure 3-8)
i.e., 4 inputs are mapped to 1 output.
The 8 S-boxes are specified in Fig. 3-9 to 3-16:
Two of these tables are shown below.
The output of the eight S-boxes is permuted as shown in Fig. 3-17.
This is to ensure that the output of an S-box in one round
affects the input of multiple S-boxes on the next round.
What's So Special about DES?
The S-boxes!
Are they random? No one knows.
Playing around with the S-boxes can be dangerous!
International Data Encryption Algorithm (IDEA):
Encrypts 64-bit blocks using 128-bit key.
It is similar to DES since it:
Operates in rounds.
The mangler function runs in the same direction for both encryption and
decryption.
Fig. 3-18 shows the basic Structure of IDEA:
IDEA operations:
® Exclusive OR
+ Addition mod 216 and
x Multiplication mod 216
These operations are reversible:
a®K=A »
A®K = a
a + K = A » A + (-K) = a
a x K = A » A x (K-1) = a
Key Expansion:
The 128-bit key is expanded into:
Fifty two 16-bit-keys: K1, K2 , ....K52.
After generating the first 8 keys (Fig. 3-19),
Shift 25 bits and continue the generation (Fig. 3-20).
since (a ® K) ® K = a
since (a + K) + (-K) = a
since (a x K) x (K-1) = a
Figure 3-20
Rounds:
Total number of rounds: 17:
odd: 1, 3, ...17 & even 2, 4, .., 16
Odd Round: (Fig. 3-21)
This is reversible using the inverse keys.
Even Round: (Fig. 3-22)
How to reverse?
Just apply it again, using the same keys
(not the inverse keys as in the odd rounds!).
Why?
From Figure 3-22 we have:
X'a = Xa ® Yout
X'b = Xb ® Yout
Yin = Xa ® Xb
Thus:
X'a ® X'b = (Xa ® Yout ) ® (Xb ® Yout)
= Xa ® Xb
= Yin
Yin is the same if we use either (Xa , Xb) or (X'a , X'b)
Similarly,
Zin is the same if we use either (Xc , Xd) or (X'c , X'd)
Thus,
Yout & Zout are the same in both encryption and decryption.
Since we know Yout and Zout we can get:
X'a ® Yout = (Xa ® Yout) ® Yout = Xa
Similarly we can get: Xb, Xc and Xd
Inverse Keys for Decryption:
Encryption keys:
K1
K2
Decryption Keys:
K3
K4
K5
K6
(K49)-1 -(K50) -(K51) (K52)-1 K47 K48
......
......
Advanced Encryption Standard (AES):
Developed with the help of NIST as an
Efficient, Flexible, Secure and
Unencumbered (free to implement)
Encryption Standard for protecting:
sensitive, non-classified, U.S. government information.
NIST selected an algorithm called Rijndael,
named after two Belgium cryptographers.
It uses a variety of key sizes:
128, 192 and 256
and the standards are named:
AES-128, AES-192, AES-256
Block sizes are fixed in all to 128 bits.
It is similar to both DES and IDEA in that there is
rounds and key expansion.
Basic Structure: (Figure 3-23)
Nb: the number of 32-bit words in an encryption block.
for AES-128: Nb = 4.
Nk: the number of 32-bit words in an encryption key.
for AES-128: Nk = 4.
Nr: the number of rounds. It should be large enough to allow sufficient
mixing
so that each bit of a plain text block or a key has a complex effect on
each bit of the resulting cipher text.
Nr = 6 + Max (Nb, Nk),
For AES-128: Nr = 10.
Primitive Operations:
• ® XOR
• Octet-Substitution (S-box, Figure 3-24)
• Rearrangement of octets (rotating rows and columns)
• MixColumn operation: Replace a column with another:
• Each octet of the input column is used as index to retrieve a column
from a table (Figure 3-26).
• Each retrieved column is rotated and
• The four rotated columns are ®'d to produce the output column (Figure
3-25).
Rounds:
• Each round is an identical sequence of 3 operations:
• Each octet of the state has the S-box applied.
For AES-128:
Row i of the state is rotated left i columns (i=0, 1, 2, 3).
• Each column of the state has MixColumn applied to it
Figure 3-26. MixColumn Table
Key Expansion:
Arrange the key as Nk columns and
Iteratively generate the next Nk columns (see Figure 3-29 and 3-30).
The Ci are constants defined in Figure 3-31.
Inverse Rounds:
Since each operation is invertible, decryption is done by performing the
inverse of each operation in the opposite order and using the round keys in the
reverse order.
Inverse Cipher:
•
•
•
•
® is its own inverse
The inverse of S-box is given by a different table (Fig 3-27)
Rotating is inverted by another rotation in the opposite direction.
The inverse of MixColumn is called InvMixCoumn
is similar to MixColumn using a different table (Fig 3-28).
RC4
RC4 is a stream cipher designed by Ron Rivest.
A long random string is called a one-time pad.
Page 93 gives a C code for RC4 one-time pad generator.
A stream cipher generates a one-time pad and applies it to a stream of plain
text with ®.
Block Chaining: Encrypting a Large Massage
Electronic Code Book (ECB):
Break the message into 64-bit blocks (padding the last one) and
Encrypt each block with the secret key.
Two problems:
• Two identical plaintext blocks produces two identical cipher blocks
• Blocks can be rearranged or modified.
Example: See Fig. 4-3 where an eavesdropper:
• Can see which sets of employees have identical or similar salaries &
• Can alter own salary to match another employee with higher salary.
Cipher Block Chaining (CBC):
See Figure Fig. 4-5 (encryption) & Fig 4-6 (decryption).
IV (Initialization Vector) is a randomly chosen number.
Two identical plain messages produce two different cipher messages.
Thus “continue holding”, “continue holding”... “Start attack” produces
different cipher blocks.
This also prevents the Chosen plain text attach.
CBC Threat: Modifying Cipher Blocks
You can modify the contents of one cipher block to make the plain text of next
block as you wish. However the preceding plain text block will be garbled.
For example in Figure 4-6:
To change m6 to m'6, we can change c5 to c'5,
Where c'5 is computed as: (c5 ® m6 ) ® m'6
However, the content of m5 will be garbage.
E.g: change Jo Tacker salary from ~$54K to ~$74K:
Note: if some bits of one cipher text get garbled (not by design),
two plain text blocks get garbled.
Output Feedback Mode (OFB):
It is a stream cipher, Encryption/Decryption is performed by X®ing the
message with one-time pad generated as follows:
1. A 64-bit IV is generated (and is transmitted with the encrypted message).
2. b1 is the DES encryption of IV with the secret key.
3. bi , i > 1, is the DES encryption of bi-1 with secret key.
4. The resulting one-time pad is: b1 | b2 | b3 | .......
5. ci = bi ® mi for i =1, 2, ...
Major advantages of OFB:
The pad can be generated in advance of the message arrival.
Note that if some bits of one cipher text get garbled, only the corresponding
bits in the plain text get garbled.
This can be bad as it will not raise suspicion if intentionally changed to
make specific changes to a plain text (e.g., give salary raise!).
Major disadvantages of OFB:
• If one block is lost, the rest of the blocks will be garbled.
• If data is stored on disk, you can not randomly read any block unless you
decrypt all the preceding blocks.
• If the <plaintext m, ciphertext c> are known by Trudy,
he can modify m into anything he wants m'.
How?
• Calculate:
X=c®m
c' = m' © X
• Sends: c' instead of c.
• The receiver calculates: c' © X = (m' © X) © X = m'
Cipher Feedback Mode (CFB):
CFB solves the first two problems of OFB:
• If one block is lost, only the next block is garbled and the rest of the blocks
will decrypt properly.
• To randomly access one block, you only need to access the preceding block.
CFB steps:
1. A 64-bit IV is generated (and is transmitted with the encrypted message).
2. b1 is the DES encryption of IV with the secret key.
3. bi , i > 1, is the DES encryption of ci-1 with secret key.
(Thus you can't generate a one-time pad in advance like OFB)
4. ci = bi ® mi for i =1, 2, ...
Counter Mode (CTR):
CTR (Figure 4-10)
Advantages:
• You can generate the one-time pad in advance.
• You can randomly access any block without decrypting all the
preceding blocks.
Disadvantage:
If one block is lost, the rest of the blocks will be garbled.
Figure 4-10
Multiple Encryption DES
It is called 3DES or EDE (encrypt-decrypt-encrypt):
m>>>> E >>>> D >>>> E >>>>c
|
|
|
K1
K2
K1
|
|
|
c >>>> E >>>> D >>>> E >>>> m
CBC is used for stream encryption as shown is Fig. 4-15:
Why EDE instead EEE?
P >>> P-1 . P >>> P-1.P >>> P-1
E
E
E
P >>> P-1. P-1 >>> P. P >>> P-1
E
D
E
Thus, there is security gain by having permutation done between stages
using EDE.
Hashes and Message Digests
A hash or message digest, is a one-way function since it is not practical to reverse.
A function is cryptographically secure if it is computationally infeasible to find:
• A message that has a given message digest.
• A different message with the same message digest.
• Two messages that have the same message digest.
Major Algorithms:
• Ron Rivest Message Digest MD-family (MD2, MD4 and MD5): 128-bit.
• NIST Secure Hash Algorithm SHA-1: 160-bit.
They take an arbitrary-length string and map it to a fixed-length quantity that
appears to be randomly chosen.
For example, two inputs that differ by only one bit should have outputs that
look like completely independently chosen random numbers.
Ideally, the message digest function should be easy to compute.
Like secret key algorithms, digest algorithms tends to be computed in rounds.
The designers finds the smallest number of rounds necessary before the output
passes various randomness tests and then add few more to be safe.
The Birthday Problem/Bound
What is the minimum number of persons in a room so that
the odds are better than 50% that two of them will have the same birthday?
Answer: 23 persons
Why?
Let n be the number of persons and k be the number of birth dates (k = 365).
There are P = n(n-1)/2 pairs of persons.
The probability that a given pair have the same birth date is 1/k.
Therefore for at least 50% probability to find a match:
P * (1/k) > 1/2
P > k/2
n(n-1)/2 > k/2
n(n-1) > k
n2 > k or
n ~ √𝒌
In general:
If the message digest is m bits then k=2m and we need to examine at least 2m/2
messages
before we could find two message with the same digest.
Example: if m = 64 we need
232 (= 4.109 or 4 billion) messages instead of
264 (= 18.1018 or 18 bilion billion) messages.
Suppose that the first authenticated message of a transaction is always the
same
“Are you ready to receive a transaction?”
If two transactions use the same authentication key,
Then the MAC value of their first message will also be the same.
The Birthday Attacks
By knowing that the two keys are the same, the attacker can insert a different
recorded message from an older transaction into the newer transaction.
Meet-in-the-Middle Attacks
Instead of waiting for a key to repeat, you can build a table of 2m/2 random
keys and for each of these keys compute the MAC of the “Are you ready to
receive a transaction?”. Eavesdropping on each transaction may reveal the
key and then the attacker may insert arbitrary message into the new
transaction.
Things to do with a Hash
Authentication:
Alice authenticating Bob:
Alice
challenge:
response:
r >>>>>>>
d <<<<<<<
Bob
r
d =MD{K|r}
- r
is a random number,
- MD{K|r} is the message digest of K concatenated with r.
Alice computes MD{K|r} and if = d, then Bob must know K.
Computing a MAC:
Using Secret Key K between Alice & Bob
Alice
Bob
m,d where d = MD(K|m) >> m,d , OK if d = MD (K|m)
K is the shared secret between Alice and Bob
Message Append Attack:
This works for some MD algorithms that have the following
property:
if d=MD(x) then for some y, d'=MD(x|y) = d+MD(y)
Traudy may intercepts <m, d> and replace it with <m', d'>,
where m'=m|y and d'=d+MD(y).
Bob receives <m', d'> and will compute:
MD(K|m')=MD(K|m|y)=MD(K|m)+MD(y)=d+MD(y)=d'
Thinking that Alice send m' !
How to avoid this flow?
- Compute MD ( m | K ) instead of MD ( K | m ).
- Compute MD ( K | m | K ).
- Compute MD ( K | MD (K | m) ).
Encryption:
Generating one-time pad:
Both Alice and Bob know the shared secret K and generate:
b1= MD(K)
bi = MD(K|bi-1), i=2,3, ....
Alice
send ci = mi ® bi
>>
Bob
recv ci and compute mi = ci ® bi
Using Secret Key for a Hash:
Unix Password Hash
Unix uses a modified DES to compute the hash of a password.
(to prevent DES hardware from cracking Unix passwords).
• DES secret Key:
Pack the 7-bit ASCII associated with each of the first eight characters of
the password into 56-bit DES key.
• Salt:
A 12-bit random number (salt) is stored with the hashed password to prevent
dictionary attack.
The salt is used to modify the DES data expansion algorithm.
• Hashed password:
The modified DES is used with the secret key to encrypt the constant 0.
The result is stored with the salt as the user's hashed password.
Example:
% ypcat passwd | grep wahab
wahab:stg/i.0xxJ1zU:51:13:Dr. wahab:/home/wahab:/usr/local/bin/tcsh
st is the salt, g/i.0xxJ1zU is the 64 bit encryption of 8 char key
(In base-64 encoding 64 bit block requires 64/6=11 char).
Note that you may have the same passwords on different UNIX sites
(e.g., ODU and UNC) but the passwd entries will be different!
MD2
It takes a message of arbitrary length and produces 128-bit message digest.
Padding:
The message must be multiple of 16 octets (128-bit).
If the message is already multiple of 16 octets,
16 octets of padding are added.
Otherwise p octets (1<= p <=15) are added.
Each pad octet contains the value n of padding, 1<=n<=16.
Note that there must always be padding.
Example:
consider a message m of 10 bytes: "abcdefghij"
the padding length is 6 and the padded message is:
"abcdefghij666666"
Checksum: Fig. 5-4
A 16-byte checksum is appended to the message before computing the MD.
Figure Fig. 5-5 is used for Pi substitution
Is it the binary representation of pi, one octet at a time? No!).
Final Pass: Fig. 5-6
MD4
Was designed to be a 32-bit word oriented so it can be computed faster on 32-bit
CPUs than an octet-oriented MD2.
MD5
Was designed to be more concerned with security than speed.
All the MD family produces 128-bit digest.
SHA-1
Designed by NIST to produce 160-bit digests
It is more secure than MD5 but little slower.
HMAC (hash-based MAC) Fig, 5-10 :
HMAC prepends the key to the data, digests it, and then prepends the key to the result
and digests that:
MD ( K | MD ( K | m ) )
It takes a variable-length key and a variable-sized message and produces a fixed-size
output of the same size as the underlying digest algorithm.
The key is padded with 0s to be 512 bits.
Public Key Cryptography
All secret key algorithms & hash algorithms do the same thing
but public key algorithms look very different from each other.
What is common among all of them is that
each participant has two key: public & private,
and most of them are based on modular arithmetic.
Modular Arithmetic
x mod n is the remainder of x when divided by n.
e.g., 8 mod 10 = 8,
18 mod 10 = 8,
24 mod 10 = 4
8 mod 7 = 1,
18 mod 7 = 4,
24 mod 7 = 3
Addition:
Example: addition mod 10
8 + 8 = 6,
1 + 9 = 0,
7+6=3
See Fig. 6-1 for addition mod 10 Table:
Encryption: Addition mod 10 can be used for encryption of digits.
Add k, a secret key between 1-9 to each digit.
Example: if k = 7, then 1987 is encrypted to 8654.
Decryption: Add -k, the additive inverse of k, to each digit.
An additive inverse of x is the number you'd have to add to x to get 0.
Example: if k = 7, then -k is 3 since 7+3 = 0
Thus 8654 will is decrypted to 1987.
In the above table (Fig. 6-1), each "0" is the intersection of
k and -k, e.g., 0 is the intersection of 3 and 7.
Multiplication:
Example: multiplication mod 10 :
8 x 8 = 4, 1 x 9 = 9 , 7 x 6 = 2
See Fig. 6-2 for multiplication mod 10 Table:
Encryption: multiplication by 1, 3, 7, 9 works as a cipher
since it performs 1-1 mapping.
Example: if k = 7, then 1987 is encrypted to 7369
Decryption: is done by multiplying each digit by k-1 ,
the multiplicative inverse of k.
It is the number to multiply by k to get 1.
Example: if k = 7, then k-1 is 3 since 7x3 = 1
In the above table (Fig. 6-2),
each "1" is the intersection of k and k-1.
Note that only {1,3,7,9} have multiplicative inverse mod 10.
What is so special about the set {1,3,7,9}?
These numbers are relatively prime to 10,
i.e., they do not share with 10 any common factors other than 1.
Note that 9 is not a prime number but it is relatively prime to 10.
Only numbers that are relatively prime to n have multiplicative
inverses.
How many numbers less than n are relatively prime to n?
This quantity is referred to as:
Ø(n) and is called the totient function.
• If n is prime:
then {1,2, ..., n-1} are all relatively prime and
thus Ø(n) = n-1.
• If n = p.q where p and q are two distinct primes,
then Ø(n) = (p-1)(q-1).
Why is that?
There are p multiples of q, q multiples of p and 0 that are not
relatively prime to n=pq.
Thus Ø(n) = pq –(p+q-1) = (p-1)(q-1)
Example: for n = 10 = 2.5, Ø(10) =(2-1).(5-1)=1.4=4,
which is the set {1,3,7,9}.
Exponentation:
Example: exponentiation mod 10
4 2 = 6, 8 8 = 6, 19 = 1 , 76 = 9
See Fig. 6-3 for exponentiation mod 10 Table:
Amazing fact about Ø(n):
x m mod n = x m mod Ø(n) mod n
Since Ø(10)=4, in Fig. 6-3:
x m mod 10 = x m mod 4 mod 10
The ith column is identical to the i+4th column,
e.g., 1st =5th =9th and 3rd = 7th =11th.
Special case:
if m = 1 mod Ø(n), then for any number x,
x m mod n = x mod n.
Example: For n =10, Ø(10)=4
Since m = 9 is 1 mod 4:
39 mod 10 = 3 mod 10 = 3 &
69 mod 10 = 6 mod 10 = 6
in general:
for any x : x9 mod 10 = x mod 10 = x
An exponentiative inverse of e is the number d such that:
e.d = 1 mod Ø(n)
Example: For n= 10, Ø(10)=4:
e=3 and d=7 are exponentiative inverses since:
3.7 = 21 = 1 mod 4
Encrypt/Decrypt:
• To encrypt m: compute c = me mod n
• To decrypt c: compute m = cd mod n
Example:
encrypt m = 8: c = 83 = 2
decrypt c = 2: m = 27 = 8
Sign/Verify:
• To sign m: compute s = md mod n
• To verify s: compute m = se mod n
Example:
sign m = 8: s = 87 = 2
verify s = 2: m = 23 = 8
In public cryptography:
<e, n> is public key
&
<d, n> is private key
Note that:
If n = p.q where p and q are two distinct primes,
then Ø(n) = (p-1)(q-1).
The relation between e and d:
e.d = 1 mod Ø(n)
To computer d you must know Ø(n) which is very hard to compute
from knowing n.
RSA: Rivest, Shamir & Adleman
Key length:
Variable (long for security, short for efficiency).
Most common values is 512 & 1024 bits.
Block size:
plain text length is variable but less than key length &
cipher text length equals key length.
Thus RSA is used for encrypting small amount of data, e.g., a
secret key
and then use the secret key cryptography for
encrypting/decrypting large amount of data.
RSA Algorithm:
Generate public & private keys pair:
1. Choose two distinct large primes p and q.
(Typically 256 bits each & keep them secret).
2. Compute n = p.q & Ø(n) = (p-1)(q-1).
(Note that it is very hard to factor n into p & q ).
3. Choose a number e that is relatively prime to Ø(n).
4. Find a number d that is the exponentiative inverse of e
i.e., e.d = 1 mod Ø(n).
5. The public key <e,n> & the private key <d,n>.
Encrypt/Decrypt:
To encrypt a message m ( less than n):
c = me mod n
To decrypt c:
m = cd mod n
This works since:
cd mod n = (me)d mod n
= me.d mod n
= m mod n // since e.d = 1 mod Ø(n)
=m
// since m < n
Sign/Verify:
To sign a message m ( less than n):
s = md mod n
To verify s:
m = se mod n
This also works since:
se mod n = me.d mod n = m mod n = m
Why is RSA Secure:
Every one knows the public key: < e, n >.
To find the private key < d, n > you need to know Ø(n)
since e.d = 1 mod Ø(n).
To know Ø(n) you need to know p and q since
Ø(n) = (p-1).(q-1).
Thus to break RSA you should know:
how to factor n to find p and q.
Factoring a big number like n is hard.
The best technique to factor 512 bit number takes 30,000 MIPSyears!
Efficiency of RSA Operations:
Exponentiation
How to compute 12354 mod 678?
1232 = 123.123 = 15129 = 213 mod 678
1233 = 123.213 = 26199 = 435 mod 678
1234 = 123.435 = 53505 = 621 mod 678
......
12354 = ......
= 87 mod 678
This requires 54 small number multiplications
and 54 small number divisions.
How to compute 12332 mod 678?
1232 = 123.123 = 15129 = 213 mod 678
1234 = 213.213 = 45369 = 621 mod 678
1238 = 621.621 = 385641 = 537 mod 678
12316 = 537.537 = 288369 = 219 mod 678
12332 = 219.219 = 47961 = 501 mod 678
This requires 5 multiplications
and 5 divisions instead of 32.
To efficiently compute 12354 : 54 is represented in binary as:
1
1
0
1
1
0
|
|
|
|
|
2
2
2
(((( (123 )123
)
) 123
)2123
)2
This requires 8 multiplications and 8 divisions instead of 32.
Each 1 requires two multipliactions and two divisions
and each 0 requires one multipliaction and one division.
Thus in the above we have three 1s and two 0s
and that yields: 3.2 + 2.1 = 8.
Note that we ignore the leading 1.
Another example: y14 , 14 is represented in binary as:
1
1
|
1
|
0
|
((
( y2) y
) 2y
)2
This requires 5 multiplications and 5 divisions instead of 32.
Generating RSA Keys
Finding e:
Two popular values for e are: 3 (21+ 1) and 65537 (216 + 1).
Other common values: 5 (22+ 1) and 17 (24+ 1).
These make public key operations on message m faster
(encryption and signature verification is me):
- m3 requires 2 multiplications & 2 divisions.
- m65537 requires 17 multiplactions & 17 divisions
since the binary value of 65537 is 100..01 (15
zeros).
Finding n:
Randomly choose p and q
and make sure that they are not 1 mod e.
n = p.q &
Ø(n) = (p-1)(q-1).
Finding Big Primes:
For a random 100 digit number (typical size for RSA), the chance is 1
in 230 being a prime.
How to test if a number p is prime? We use:
Fermat’s Theorem:
If p is prime and 0< a <p, ap-1 = 1 mod p
A primality test then is to pick a number a < p and compute ap-1 mod
p:
• If the answer is not 1, p is not prime.
• If it is 1 the probability that p is not a prime is ~ 1/1013
If the risk of 1 in 1013 is unacceptable, repeat the test using multiple
values of a.
Finding d:
How to fine d such that e.d = 1 mod Ø(n) ?
Use Euclid algorithm (see Section 7.4, page 187 of textbook).
The RSA keys:
public key: <3 | 65537, n>
Precautions when using e=3:
private key: <d , n>.
𝟑
• If a message m to be incrypted is small < √𝒏 then raising m to the
power of 3 mod n will simply produce the value c = m3 < n. Thus any
one can decrypt it by taking a cubec root of c to produce m.
The problem can be avoided by padding the message with a random
number before encyption so that m3 need to be reduced mod n.
• If a message m is send to 3 receipients with public keys: <3, n1>,
<3, n2>, <3, n3> and if a bad guy sees: m3 mod n1 , m3 mod n2, m3
mod n3. Then he can use the Chinnese Remainder Theorem (CRT)
to compute m3 mod n1n2n3 from these 3 values. Since m is smaller
than each of ni , m3 will be smaller than n1n2n3 and the bad guy gets
m by computing the cubec root of m3 .
The problem can be avoided by padding the message with the ID of
each recipient.
Optimizing RSA Private Key Operations:
• In RSA, d and n=pq are on the order of 512-bit numbers
While p and q are on the order of 265-bits.
• RSA private key operations takes a message c in the order of 512bits and computes:
m = cd mod n.
• We can use the CRT to speed up the RSA operations using mod p
and mod q instead of mod n.
i.e. using 256-bits instead of 512-bits operations. The following is
known as Garner’s Formula:
m = (((a-b)( q-1 mod p)) mod p).q + b
where:
a = cp dp mod p & b = cq dq mod q
cp = c mod p
& cq = c mod q
dp = d mod (p-1) & dq = d mod (q-1)
Diffie-Hellman
Alice and Bob agree on: p (large prime) & g < p.
Alice
Pick SA (512-bit random number)
bit random number)
Compute TA = ( gSA) mod p
(gSB) mod p
TA
>>>
S
Compute X = TB A mod p
TA SB mod p
X is the same as Y!
why?
X = (TB) SA = (gSB) SA
Y = (TA) SB = (gSA) SB
Bob
Pick SB (512Compute TB =
<<<
TB
Compute Y =
No one can compute g (SASB) by knowing g (SA ) & g (SB )
The bucket Brigade/Man-in-theMiddle Attach
Alice
Mr. X
Bob
Pick SA
Pick SX
Pick SB
S
S
Compute: TA = g A mod p
TX = g X mod p
TB = gSB
mod p
TA
TA .. TX
TX
>>
>>
TX
TX .. TB
TB
<<
<<
S
S
Compute: KAX = TX A mod p
KAX = TA X mod p
KBX =
S
TX B mod p
KBX = TB SX mod p
Possible Defense
• Each person i picks Si and computes Ti = gSi mod p and
keeps
Si private & makes Ti public
• If Alice like to communicate with Bob, she finds TB and
computes:
KAB = TB SA mod p
• Then tells Bob she likes to communicate with him.
• Bob finds TA and then computes:
KBA = TA SB mod p
This requires PKI (Public Key Infrastructure) to manage Ti
El-Gammal Signature
• Each person has long-term public/private key pair:
Private: S
Public: < g, p, T > where T = gS mod p
• For each message m to be signed:
1. For each message m, generate a per-message
public/private key pair:
Private: Sm
Public: Tm = gSm mod p
2. Compute the message digest: dm = MD ( m | Tm )
3. Compute the message signature: X = Sm + dm S mod (
p -1 )
4. Send: m, Tm and X
Verify:
• Compute the message digest: dm = MD ( m | Tm )
• Compute: Y1 = gX and Y2 = Tm T dm
If Y1 = Y2 then the signature is correct.
Why?
Since X = Sm + dm S mod ( p -1 ),
Tm = gSm mod p
T = gS mod p
Y1 = g X = gSm + dmS = gSm gdmS = Tm gS dm= Tm T dm = Y2
Digital Signature Standard (DSS)
Proposed by NIST based on a modified version of ElGammal algorithm.
Zero Knowledge Proof Systems
Example:
Graph isomorphism problem:
We consider two graphs isomorphic if we can rename the
vertices of one to get a graph identical to the other.
This is a well-known NP-complete problem.
f >
g >
h >
i >
j >
A
B
C
D
E
>
>
>
>
>
1
2
3
4
5
Alice specifies a large graph GA and renames the vertices to
produce another isomorphic graph GB.
Public Key: ( GA , GB )
Private Key: GA  GB
To prove to Bob that she is Alice:
• She renames the vertices to produce a set of
isomorphic graphs: G1 G2 .... Gk and sends them to
Bob.
• Bob asks Alice to show him for each i the mapping
between: Gi and either GA or GB but not both,
(Otherwise Bob may know her private key!)
Number Theory
Primes numbers
A positive integer p is prime iff it is evenly divisible by exactly two positive
integers: itself and 1.
• The single digits primes are 4 numbers:
2357
• The two digits primes are 21 numbers:
11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97
• The three digits primes are 143 numbers:
101 103 107 109 113 127 131 137 139 149 151 157 163 167 173 179 181 191
193 197 199 211 223 227 229 233 239 241 251 257 263 269 271 277 281 283
293 307 311 313 317 331 337 347 349 353 359 367 373 379 383 389 397 401
409 419 421 431 433 439 443 449 457 461 463 467 479 487 491 499 503 509
521 523 541 547 557 563 569 571 577 587 593 599 601 607 613 617 619 631
641 643 647 653 659 661 673 677 683 691 701 709 719 727 733 739 743 751
757 761 769 773 787 797 809 811 821 823 827 829 839 853 857 859 863 877
881 883 887 907 911 919 929 937 941 947 953 967 971 977 983 991 997
• A list of the 10,000 smallest prime numbers is available at:
http://www.math.utah.edu/~pa/math/p10000.html
• There are infinitely many primes.
• Primes do thin out as numbers get bigger:
o The density of primes < 2 digit numbers is 1 / 4.
o The density of primes < 3 digit numbers is 1 / 6.
o The density of primes < 10 digit numbers is 1 / 23.
o The density of primes < 100 digit numbers is 1 / 230.
In general, the density is inversely proportional to their length in digits.
• In RSA a common size prime is 100 digit and thus a random 100 digit has a
chance of 1 in 230 of being prime.
i.e., on average it will be necessary to select 230 hundred digit numbers
before a prime is found.
Euclid’s Algorithm
Finding the multiplicative inverse m-1 of m (mod n) ,
where m and n are relatively primes (the GCD of m and n is 1).
Initial Step:
r-2 = m, u-2 = 1, v-2 = 0
r-1 = n, u-1 = 0, v-1 = 1
i=0
Step i:
If ri-1 = 1 then ui-1 is the multiplicative inverse m-1 of m (mod n).
Otherwise:
Divide ri-2 by ri-1 to get quotient qi and remainder ri
Set ui = ui-2 - qi ui-1 & vi = vi-2 - qi vi-1
Set i = i + 1
Repeat
Example 1:
m=7, n = 10
qi
ri
ui
vi
i
-2
7
1
0
-1
10
0
1
0
0
7
1
0
1
1
3
-1
1
2
2
1
3
-2
-1
Since r2 is 1 then m is 3
Example 2:
m=7, n = 15
i
qi
ri
ui
vi
-2
7
1
0
-1
15
0
1
7
1
0
1
-2
1
0
0
1
2
-1
Since r1 is 1 then m is -2 mod 15 = 13
Example 3:
m=797, n = 1047
i
qi
ri
ui
vi
-2
797
1
0
-1
1047
0
1
0
0
797
1
0
1
1
250
-1
1
2
3
47
4
-3
3
5
15
-21
16
4
3
2
67
-51
5
7
1
-490
373
-1
Since r5 is 1 then m is -490 mod 1047 = 557
The Chinese Remainder Theorem (CRT)
If p and q are relatively prime, then any number x has two equivalent
representations:
Standard: x mod pq
Decomposed: a=x mod p & b=x mod q
To covert from decomposed to standard we use Garner’s Formula:
x = (((a-b)( q-1 mod p)) mod p).q + b
The CRT can be used to speed up the computation is RSA and other
cryptography applications.
Euler’s Theorem:
Zn*
Zn = {i >=0: i <n}
Example: Z10 = {0,1,2,3,4,5,6,7,8,9}
Zn* = {i > 0: i <n and is relatively prime to n}
Example: Z10* = {1,3,7,9}
If you multiply any two numbers in Z10* you get another number in Z10*
Each raw and column in the Z10* multiplication table contains all the elements
of Z10* with no repeats.
1
3
7
9
1
1
3
7
9
3
3
9
1
7
7
7
1
9
3
9
9
7
3
1
Z10* Multiplication table
Zn* is closed under multiplication mod n.
Euler’s Totient Function
Ø(n) (called Euler’s Totient Function) is the number of elements in Zn*.
Example: Ø(10) = 4.
• If n is prime, then Ø(n) = n-1
• If n = pq where p and q are relatively prime, then
Ø(n) = Ø(p) Ø(q)
• If n= pq where p and q are primes, then Ø(n) = (p-1)(q-1).
Example: 10 = 2.5 and thus Ø(10) = (2-1).(5-1)=1.4=4
Euler’s Theorem:
For all a in Zn*: aØ(n) = 1 mod n
Generalized Euler’s Theorem:
If n = pq where p and q are distinct primes, then
For all a in Zn (not just Zn*): akØ(n)+1 = a mod n
Public Key Infrastructure (PKI) Certifiactes
Using OpenSSL
Documentation: http://www.openssl.org/docs/apps/pkcs8.html
Certificate Requests Commands:
To generate a certificate request and sign it from CA.
In the following: replace <student> with your <login name>
% mkdir <student>_cert_request
% cd
<student>_cert_request
% cp
/home/cs772/public_html/PKI/shell_scripts/students/*
.
This copies all the shell scripts and files needed.
% gencertreq
<student>
That will create two files:
<student>_certreq.pem & <student>_privatekey.pem
To print <student>_certreq.pem
% printcertreq
<student>
Submit file <student>_certreq.pem to CA to be signed:
% mkdir
submit
% cp
<student>_certreq.pem
% cd
submit
% submit cs772
submit
The CA will sign your certificate and sends an email to copy:
<student>_cert.pem & ca_cert.pem
Then you can print these two certificates using:
% printcert
% printcert
<student>
ca
Certificate Authority (CA) Commands
To setup the necessary environment to create CA keys and root
certificate, and to sign the students certificate requests.
To create CA keys and root certificate
Copy the ca shell scripts in any directory you choose.
% cp /home/cs772/public_html/PKI/shell_scripts/ca/*
.
Edit file myopenssl.cnf to replace cs772 with your <login name>
Then create the needed files and directories:
% setup
Then create CA keys (ca_key.pem) & certificate (ca_cert.pem:.
% genca
Print certificate ca_cert.pem:
% printcert
ca
To sign certificate requests
To sign a request from a single student under:
submitted_requests/<student>_cerreq.pem
% issuecert
<student>
This produces:
signed_requests/<student>_cert.pem &
issued_certs/xx.pem where <xx> is serial number of cert.
To sign more than one certificate put the names in a file called: list and
then use:
% batch_issuecert
Application of PKI:
Secure Multipurpose Internet Mail Exchange (SMIME)
Use unix Mail to send and read your mail.
In reading a mail message: write the message to a file (e.g., w file)
Copy all the shell scripts and files needed.
% cd <student>_cert_request
% cp
/home/cs772/public_html/PKI/shell_scripts/securemail/*
.
Encrypted mail : to send/receive encrypted messages.
Send:
% sendencmail
<receiver>
<file>
The sender should have: <receiver>_cert.pem
<file> is the message to be encrypted.
This produce <file>.enc which is encrypted with a secret key.
The secret key is encrypted with the public key in <receiver>_cert.pem
Read:
First read your mail and save the msg in <file> then use the following
command:
% readencmail
<receiver>
<file>
The recipient should have:
<receiver>_cert.pem> & <receiver>_privatekey.pem
This decrypt mail in <file> using the supplied certificate and private key.
First, the secret key is decrypted using <receiver>_privatekey.pem
Then <file> is decrypted with the secret key.
Signed mail to send/receive signed messages
Send:
% sendsignmail
<receiver>
<file>
<sender>
The sender should have:
<sender>_cert.pem & <sender>_privatekey.pem
To sign <file> using the <sender> certificate and private key.
The signed message as well as the <sender> certificate are written to the output
<file> .sig
Read:
First read your mail and save the msg in <file> then use the following
command:
% readsignmail
<file>
The recipient should have: ca_cert.pem
This verifies signed <file> using the sender’s certificate and the CA certificate.
and outputs the sender’s information and the message content.
Signed +Encrypted mail to send/receive signed and encrypted messages
Send:
% sendsign_encmail <receiver> <file> <sender>
The sender should have: <receiver>_cert.pem,
<sender>_cert.pem & <sender>_privatekey.pem
This signs the <file> using the <sender> certificate and private key.
The signed file as well as the <sender> certificate are written to the output
<file> .sig which is then encrypted to <file>.enc using a secret key.
The secret key is encrypted with the public key in <receiver>_cert.pem
Read:
First read your mail and save the msg in <file> then use the following
command:
% readsign_encmail
<receiver> <file>
The reciepient should have: <receiver>_cert.pem,
<receiver>_privatekey.pem & ca_cert.pem
This first decrypts mail in <file> using the receiver certificate and private key.
The secret key is decrypted using <receiver>_privatekey.pem
Then <file> is decrypted using the secret key.
It then verifies the signed <file> using the sender’s and CA certificates.
Finally it outputs the sender’s information and the message content.
Sign then Encrypt Versus Encrypt then Sign?
Sign then Encrypt:
• A wants to send B a message M as signed then encrypted message.
Sign M as M’ and then encrypt M’ as M” and mail M” to B.
• B decrypts M” to M’ and verify that M’ was sent as M from A.
• if B wants to forwards the message M’ to C,
B can forwards the signed message M’ to C.
C can reads the message M and verify that A is the author.
Encrypt then Sign:
• A wants to send B a message M as encrypted then signed message.
Encrypt M as M’ and then sign M’ as M” and mail M” to B.
• B verifies M” was signed by A and then M’ decrypted to read M.
• If B wants to forward the message to C, then he can send M”.
C can verify that M” was signed by A.
However C can NOT decrypt M’ to read the message M since he does
not have the private key of B!
Email Security Protocols
PEM & S/MIME
PEM (Privacy Enhanced Mail):
Add encryption, authentication and integrity to ordinary text messages.
MIME (Multipurpose Internet Mail Extensions):
Is a standard for encoding arbitrary data in email (images, video, etc.).
S/MIME:
Incorporated many principles of PEM into MIME.
Structure of a PEM Message
PEM marks its pieces with a text string before and after the piece as:
-----BEGIN PRIVACY ENHANCED MESSAGE----......<data>....
-----END PRIVACY ENHANCED MESSAGE-----
The different types of pieces PEM can combine into a message are:
1. Ordinary, unsecured data.
2. Integrity-protected unmodified data (MIC-CLEAR).
3. Integrity-protected encoded data
(MIC-ONLY).
4. Encoded encrypted integrity-protected data (ENCRYPTED).
Not only these types of data be combined in a message, but they can be
nested inside one another.
E.g., Alice might enclose MIC-CLEAR message from Fred
in an ENCRYPTED message to Bob.
Example:
From: Alice
To: Bob
Subject: Colloquium
Date: Mon Oct 7, 2010
Dear Bob:
I would like to invite you to give a colloquium next Spring at ODU,
if you accept, let us talk about the details.
Alice
The above message may be sent in one following 3 forms:
MIC-CLEAR
From: Alice
To: Bob
Subject: Colloquium
Date: Mon Oct 7, 2010
-----BEGIN PRIVACY ENHANCED MESSAGE----Proc-Type: 4, MIC-CLEAR
Content-Type: RFC822
Originator-ID-Asymmetric: <certificate ID>
MIC-Info: RSA-MD5, RSA, <encoded MIC>
Dear Bob:
I would like to invite you to give a colloquium next Spring at ODU,
if you accept, let us talk about the details.
Alice
-----END PRIVACY ENHANCED MESSAGE-----
MIC-ONLY
From: Alice
To: Bob
Subject: Colloquium
Date: Mon Oct 7, 2010
-----BEGIN PRIVACY ENHANCED MESSAGE----Proc-Type: 4, MIC-ONLY
Content-Type: RFC822
Originator-ID-Asymmetric: <certificate ID>
MIC-Info: RSA-MD5, RSA, <encoded MIC>
<encoded message>
-----END PRIVACY ENHANCED MESSAGE-----
ENCRYPTED
From: Alice
To: Bob
Subject: Colloquium
Date: Mon Oct 7, 2010
-----BEGIN PRIVACY ENHANCED MESSAGE----Proc-Type: 4, ENCRYPTED
Content-Type: RFC822
DEK-Info: DES-CBC, IV
Originator-ID-Asymmetric: <Originator certificate ID>
Key-Info: RSA, <encoded message key encrypted with originator public
key>
MIC-Info: RSA-MD5, RSA, <encoded encrypted MIC>
Recipient-ID-Asymmetric: <Recipient certificate ID>
Key-Info: RSA, <encoded message key encrypted with recipient public key>
<encoded encrypted message using DES-CBC>
-----END PRIVACY ENHANCED MESSAGE-----
• Why we send the message key to originator?
For CC purposes and if message is returned to sender due to some error.
• Why MIC is encrypted?
Using the public-key of the Originator, a person can compute the
message digest MD.
Then he can use the MD to check his guess for the message e.g., attack
or retreat.
• How to send an ENCRYPTED message to multiple recipients?
Encrypt the message key once for each recipient:
Recipient-ID-Asymmetric: <Recipient-1 certificate ID>
Key-Info: RSA, <encoded message key encrypted with recipient-1
public key>
Recipient-ID-Asymmetric: <Recipient-2 certificate ID>
Key-Info: RSA, <encoded message key encrypted with recipient-2
public key>
......
Recipient-ID-Asymmetric: <Recipient-n certificate ID>
Key-Info: RSA, <encoded message key encrypted with recipient-n public
key>
PEM Encoding:
It is base-64 encoding, i.e., each 6 bits is encoded as 8-bit character in the set
{A-Z,a-z,0-9,+,/}
When PEM sees a line that begins with - it is replaced with "- ".
Thus the string in the text:
-----END PRIVACY ENHANCED MESSAGE----would appear as:
- ----END PRIVACY ENHANCED MESSAGE-----
Forwarding & Enclosure:
Only MIC-CLEAR and MIC-ONLY messages can be forwarded.
For ENCRYPTED messages, it must be decrypted and then re-encrypted.
Unprotected Information:
From: Alice
To: Bob
Subject: Colloquium
Date: Mon Oct 7, 2010
To protect the header information, it should be included in the text.
Secret Key Variant:
PEM can be used for both public-key and secret-key infrastructure.
A secret key between Alice and Bob can be established using
out-of-band mechanism (e.g., phone, Kerberos).
There is no much interest in secret key based PEM.
Differences in S/MIME:
S/MIME is very similar to PEM. One difference is:
boundery=----boundery marker
----boundery marker
...<Content>....
----boundery marker
SSL/TLS Protocols
SSL (Secure Socket Layer, developed by Netscape ) &
TLS (Transport Layer Security, is an IETF standard)
Both are almost the same. They run as a user-level processes on top of
TCP/IP.
The Basic Protocol:
{===========================================
Alice
Bob
I want to talk, ciphers I support, Ra
>
<
Certificate, cipher I choose, Rb
Choose secret S, compute K= f (S,Ra,Rb):
{S}Bob , {keyed hash of handshake msgs}
>
Compute K= f(S,Ra,Rb):
<
{keyed hash of handshake msgs}
<
Data protected with keys derived from K
>
============================================}
Keys:
• Alice chooses a random number S, as pre-master secret.
• It is shuffled with Ra and Rb to produce a master secret K.
• Ra and Rb are 32 octets long. The first 4 are the UNIX time (number of
seconds since Jan 1, 1970).
This is to ensure that Rs are always different.
• The master secret is shuffled with Rs to produce six (6) keys:
 Three (3) for each side for encryption, integrity, and IV.
 The three keys used for transmission are known as the write keys
 The three keys used for reception are known as the read kyes
 Thus Alice's write keys are Bob's read keys and vice versa.
• To ensure that the keyed hash Alice sends is different from the keyed hash
Bob sends,
Alice includes the string "CLNT" and the Bob include "SRVR" in the hash.
(To avoid the Reflection attack!).
• Note that:
 Alice has authenticated Bob
(Since Bob has the secret key that corresponds to the certificate’s
public).
 Bob has no idea to whom he's talking to.
 In SSL it is optional for the server to authenticate the client, if the client
has a certificate.
 Normally the server authenticates the client using:
<name, password>
sent securely over the ssl connection.
Session Resumption
If the server supports session resumption, it sends session_id for the client at the
beginning.
{========================================
Alice
Bob
I want to talk, ciphers I support, Ra
>
<
session_id, certificate, cipher I choose, Rb
choose secret S, compute K= f(S,Ra,Rb):
>
{S}Bob, {keyed hash of handshake msgs}
compute K= f(S,Ra,Rb):
{keyed hash of handshake msgs}
<
<
data protected with keys derived from K
>
========================================}
Session resumption, if both sides remember the session_id:
{=========================================
Alice
Bob
session_id, ciphers, Ra
>
<
session_id, cipher, Rb, {keyed hash of msgs}
{keyed hash of msgs}
>
<
data protected with keys derived from K
>
=========================================}
Note that they still have to negotiate ciphers,
But the pre-master secret S is the same (since it is expensive to generate).
Encrypted Records
SeqNum | Header | Data - > HMAC <- integriy key
||
||
||
V
V
V
Header | Data | HMAC | pad - > ENCRYPT < - encryption key
||
||
V
V
Header |
encrypted-integrity-protected record
If block cipher is used, the IV is used to encrypt the first record.
The final block of each record is used as the IV for the next record.
Connection Closure
• The sender should send close_notify message to signal the other end that it has
no more data to send.
• The purpose is to prevent a trunctation attack in which the attacker inserts a
TCP FIN segment before the sender has finished sending data forcing the
receiver to think that all data has been received.
• If a party receives FIN without first receiving close_notify it must mark the
session as not resumable.
HTTP Over SSL - https
HTTP:
HTTP (Hyper Text Transfer Protocol) is the Web basic transport protocol.
The basic unit of HTTP interaction is the request/response pair:
• The client opens a TCP connection to the server and writes the request.
• The server writes back the response and indicates the end of response either
with:
length header or by closing the connection.
Example:
Client Request:
GET / HTTP/1.0
Connection: Keep-Alive
Host: www.cs.odu.edu
Serever Response:
HTTP/1.0 200 OK
Content-Length: 1650
Connection: Keep-Alive
Content-Type: text/html
............
URLs:
<scheme>://<host>[:<port>]/<path>[?<query>]
Examples:
• <scheme>: http, default <port> 80
• <scheme>: ftp, default <port> 21
• <schems>: https, default <port> 443
HTTPS:
The client makes a connection to the server;
Negotiates an SSL connection; and
Transmits http data over the established secure connection.
Reference integrity:
Match the URL reference to the server's identity with the
CN name in the server's PKI certificate.
OpenSSL: s_server & s_client
s_server:
% openssl
s_server -dhparam dh1024.pem -accept 1234
-cert server_cert.pem -key server_privatekey.pem
% openssl
s_server -dhparam dh1024.pem -accept
1234
-cert server_cert.pem
-key server_privatekey.pem
WWW
The option (WWW) causes the server to emulate a simple http server.
% openssl
s_server -dhparam dh1024.pem -accept
1234
-cert server_cert.pem
-key server_privatekey.pem
-verify 2 –CAfile ca_cert.pem
• The option (-verify) causes the server to demand a certificate from the client
and the depth of the chain should not exceed 2.
• The option (-CAfile) specify the trusted certificate.
-
To create the dh1024.pem:
% openssl dhparam -check -text -5 1024
-out
dh1024.pem
Or use the option -no_dhe e.g.:
% openssl
s_server -no_dhe
-accept 1234
-cert
server_cert.pem
-key server_privatekey.pem
s_client:
% openssl
2
s_client
-CAfile ca_cert.pem
% openssl
s_client
2
-CAfile ca_cert.pem
client_privatekey.pem
% openssl
s_client
2
-CAfile ca_cert.pem
-connect
localhost:1234
-verify
-connect
localhost:1234
-verify
-cert
client_cert.pem
-connect
localhost:1234
-key
-verify
-reconnect
The option (-reconnect) causes 5 connections to the server using the same
session ID to test session cashing.
To test the WWW mode of server type:
GET
/anyfile
HTTP/1.0
SSL/TLS Programming
sslClient.c
#define CA_LIST
"ca_cert.pem"
#define ClientKEYFILE
"client.pem"
#define ClientPASSWORD
"cairo"
#define ServerHOST
"antares.cs.odu.edu"
#define PORT
10203
#define RANDOM
"random.pem"
int main (int argc, char **argv)
{
SSL_CTX
*ctx;
SSL
*ssl;
BIO
*sbio;
int
sock;
/* Build our SSL context*/
ctx = initialize_ctx (ClientKEYFILE, ClientPASSWORD);
ssl = SSL_new (ctx);
/* Connect the TCP socket*/
sock = tcp_connect ();
sbio = BIO_new_socket (sock, BIO_NOCLOSE);
SSL_set_bio (ssl, sbio, sbio);
/* Connect the SSL socket */
SSL_connect (ssl);
check_cert_chain (ssl, ServerHOST);
/* read and write */
read_write (ssl, sock);
}
int tcp_connect ()
{
struct hostent *hp;
struct sockaddr_in addr;
int sock;
hp = gethostbyname (ServerHOST);
memset (&addr,0,sizeof(addr));
addr.sin_addr = *(struct in_addr*)hp->h_addr_list[0];
addr.sin_family = AF_INET;
addr.sin_port = htons(ServerPORT);
sock = socket(AF_INET,SOCK_STREAM,IPPROTO_TCP);
connect (sock, (struct sockaddr *) &addr, sizeof(addr);
return sock;
}
/*
Read from the keyboard and write to the server
Read from the server and write to the keyboard
*/
void read_write (ssl, sock)
SSL *ssl;
{
int r, c2sl=0;
int shutdown_wait=0;
char c2s[BUFSIZZ], s2c[BUFSIZZ];
while (1) {
/* Check for input on the console*/
c2sl = read (0, c2s, BUFSIZZ);
if (c2sl == 0 ) goto end;
/* If we've got data to write then try to write it*/
SSL_write (ssl, c2s, c2sl);
/* Now check if there's data to read */
do {
r = SSL_read (ssl, s2c, BUFSIZZ);
switch (SSL_get_error (ssl, r) ) {
case SSL_ERROR_NONE:
fwrite (s2c, 1, r, stdout);
break;
case SSL_ERROR_ZERO_RETURN:
/* End of data */
goto end;
break;
default:
berr_exit("SSL read problem");
}
} while ( SSL_pending (ssl) );
}/* end of while (1) */
end:
SSL_shutdown (ssl);
SSL_free (ssl);
close (sock);
return;
}
sslServer.c
#define CA_LIST
"ca_cert.pem"
#define ServerKEYFILE "server.pem"
#define ServerPASSWORD
"cairo"
#define ClientHOST
"vega.cs.odu.edu"
#define PORT
10203
#define DHFILE
"dh1024.pem"
#define RANDOM
"random.pem"
int main (argc,argv)
int argc;
char **argv;
{
int sock, s;
BIO *sbio;
SSL_CTX *ctx;
SSL *ssl;
int r;
pid_t pid;
/* Build our SSL context*/
ctx = initialize_ctx (ServerKEYFILE, ServerPASSWORD);
load_dh_params (ctx, DHFILE);
generate_eph_rsa_key(ctx);
sock = tcp_listen ();
while (1) {
ps = accept (sock, 0, 0);
sbio = BIO_new_socket (ps, BIO_NOCLOSE);
ssl = SSL_new(ctx);
SSL_set_bio (ssl, sbio, sbio);
SSL_accept (ssl);
check_cert_chain (ssl, ClientHOST);
if (fork() == 0)
echo (ssl);
}
}
}
int tcp_listen ()
{
int sock;
struct sockaddr_in sin;
sock = socket (AF_INET,SOCK_STREAM,0);
memset (&sin,0,sizeof(sin));
sin.sin_addr.s_addr = INADDR_ANY;
sin.sin_family = AF_INET;
sin.sin_port = htons(PORT);
if ( bind (sock, (struct sockaddr *)&sin, sizeof(sin))<0)
berr_exit("Couldn't bind");
listen (sock,5);
return (sock);
}
void echo (ssl)
SSL *ssl;
{
char buf[BUFSIZZ];
int r,len,offset;
while (1) {
/* First read data */
r=SSL_read (ssl, buf, BUFSIZZ);
switch ( SSL_get_error (ssl,r) ){
case SSL_ERROR_NONE:
len=r;
break;
case SSL_ERROR_ZERO_RETURN:
goto end;
default:
berr_exit ("SSL read problem");
}
/* Now keep writing until we've written everything*/
offset=0;
while (len) {
r = SSL_write (ssl, buf+offset, len);
switch (SSL_get_error (ssl,r)) {
case SSL_ERROR_NONE:
len-=r; offset+=r;
break;
default:
berr_exit("SSL write problem");
}
}
} /* while (1) */
end:
SSL_shutdown(ssl);
SSL_free(ssl)
}
common.c
SSL_CTX *initialize_ctx (keyfile, password)
char *keyfile;
char *password;
{
SSL_METHOD *meth;
SSL_CTX *ctx;
if (!bio_err) {
/* Global system initialization*/
SSL_library_init ();
SSL_load_error_strings ();
/* An error write context */
bio_err = BIO_new_fp (stderr, BIO_NOCLOSE)
}
/* Create our context*/
meth = SSLv3_method ();
ctx = SSL_CTX_new (meth);
/* Load our keys and certificates*/
SSL_CTX_use_certificate_file ( ctx, keyfile,
SSL_FILETYPE_PEM);
pass = password;
SSL_CTX_set_default_passwd_cb (ctx, password_cb);
SSL_CTX_use_PrivateKey_file (ctx, keyfile,
SSL_FILETYPE_PEM);
/* Load the CAs we trust*/
SSL_CTX_load_verify_locations (ctx, CA_LIST,0);
SSL_CTX_set_verify_depth (ctx,1);
SSL_CTX_set_verify (ctx,
SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
verify_callback);
/* Load randomness */
RAND_load_file (RANDOM,1024*1024);
return ctx;
}
int verify_callback (int ok, X509_STORE_CTX *store)
{ char data[256];
/* to debug if (!ok) */
if (ok)
{ X509 *cert = X509_STORE_CTX_get_current_cert(store);
int depth = X509_STORE_CTX_get_error_depth(store);
int err = X509_STORE_CTX_get_error(store);
fprintf(stderr, "-Error with certificate at depth: %i\n", depth);
X509_NAME_oneline(X509_get_issuer_name(cert), data, 256);
fprintf(stderr, " issuer = %s\n", data);
X509_NAME_oneline(X509_get_subject_name(cert), data, 256);
fprintf(stderr, " subject = %s\n", data);
fprintf(stderr, " err %i:%s\n", err, X509_verify_cert_error_string(err) );
}
return ok;
}
/* Check that the common name matches the host name*/
void check_cert_chain (ssl, host)
SSL *ssl;
char *host;
{
X509 *peer;
char peer_CN[256];
if ( SSL_get_verify_result (ssl) != X509_V_OK )
berr_exit ("Certificate doesn't verify");
/*Check the common name*/
peer = SSL_get_peer_certificate (ssl);
X509_NAME_get_text_by_NID ( X509_get_subject_name (peer),
NID_commonName, peer_CN, 256 );
if (strcasecmp (peer_CN, host))
err_exit ("Common name doesn't match host name");
}
void load_dh_params (ctx, file)
SSL_CTX *ctx;
char *file;
{
DH *ret=0;
BIO *bio;
bio = BIO_new_file (file, "r");
ret = PEM_read_bio_DHparams (bio,NULL,NULL,NULL);
BIO_free (bio);
SSL_CTX_set_tmp_dh (ctx,ret);
}
void generate_eph_rsa_key (ctx)
SSL_CTX *ctx;
{
RSA *rsa;
rsa=RSA_generate_key(512,RSA_F4,NULL,NULL);
SSL_CTX_set_tmp_rsa(ctx,rsa);
RSA_free(rsa);
}
Generating the required .pem files:
#define DHFILE
"dh1024.pem"
#define RANDOM
"random.pem"
#define CA_LIST
"ca_cert.pem"
#define ServerKEYFILE
"server.pem"
#define ClientKEYFILE
"client.pem"
• To create the dh512.pem or dh1024.pem:
% openssl dhparam -check -text -5 512 -out dh512.pem
% openssl dhparam -check -text -5 1024 -out dh1024.pem
• To create the random.pem:
% cp ~/cs772/random.pem .
• To create the server.pem & client.pem:
First generate a cert request, make sure to specify: "localhost" or the actual
host name,
& host vega: use "vega.cs.odu.edu" as the CN name in vega_cert.pem
& host antares: use "antares.cs.odu.edu" as the CN name in
antares_cert.pem
Sign the hosts certificates from the CA and then do the following:
%
cat vega_privatekey.pem vega_cert.pem
ega.pem
ca_cert.pem > v
%
cat antares_privatekey.pem antares_cert.pem ca_cert.pem
> antares.pem
If you run the client on vega:
% cp
If you run the server on antares: % cp
vega.pem client.pem
antares.pem server.pem
Introduction To Authentication Systems
Password-based Authentication
It's not who you know. It's what you know
On-line Password attack:
Easy to defend, limit and slow down the number of guesses.
Off-line Password attack:
Capture a quantity X derived from the password & take your time to
guess
(e.g., use a dictionary) the password that produces X.
Storing User Passwords:
• Store password hashes.
• Encrypt the password database and safeguard the encryption key.
• Combination: Encrypt the database of hashed passwords.
Address-based Authentication
It's not what you know. It's where you are
In Unix implementations:
/etc/hosts.equiv:
Contains a list of computers that have identical user accounts.
Allow users on these hosts to login (rsh) without providing
passwords.
$HOME/.rhosts:
e.g., if at cs.unc.edu file /home/wahab/.rhosts contains:
vega.cs.odu.edu wahab
vega.cs.odu.edu maly
allows wahab and maly to login as wahab to any host at cs.unc.edu
from host vega.cs.odu.edu (maly does not know wahab's
password).
(see % man hosts.equiv for details).
Network address Impersonation:
Generally, it is not difficult for Trudy to claim Alice's address as
the source address,
but it is more difficult for Trudy to receive messages addressed
to Alice's network address.
In IP protocol, Trudy may use source routing by sending a
message with source route:
<Alice, Trudy, Bob>
and Dist will reply with source route:
<Bob, Trudy, Alice>
Thus Trudy can get the reply!
Passwords as Cryptographic Keys:
To convert a text string that is memorable by a human e.g., cairo,
into cryptographic secret key, e.g., DES key,
do a cryptographic hash of the password and take n bits of the result.
Eavesdropping & Server Database Reading
Password Hashing:
Alice
Bob
I am Alice, cairo -----------> knows hash h of Alice password
check that: h = MD(cairo)
Problem: eavesdropping.
Shared Secret:
Alice
I am Alice
-------------->
R
<-------------encrypt R: X = K{R} ------->
Bob
get Alice secret key: K
R (random)
decrypt: R = K[X]
Problem: reading the server database.
Public Key Cryptography:
Makes it easy to perform authentication that both:
• Secure against eavesdropping &
• Protects against an intruder reading the server database.
Alice
Bob
I am Alice
-----------> get Alice public key: e
R
<------------ R (random)
sign R: X = [R]d -----------> verify: R = [X]e
Trusted Intermediaries
If we have N nodes:
If each nodes keeps N-1 secrets, then adding a new node
involves
adding N new secrets, one at each node.
Clearly not practical for large N.
KDC (Key Distribution Center):
KDC knows N keys, one for each node.
Adding a new node involves only adding one key at KDC.
If Alice like to talk to Bob:
Alice
KDC
Bob
Need to talk to Bob --->
generate random R
R= KA[X] <--------------- X= KA{R}
Y= KB{R} ----------------> R= KB[Y]
C1 = R{M1} ---------------------------------------------> M1 = R[C1]
M2 = R[C2] <---------------------------------------------- C2 = R{M2}
Disadvantages of KDC:
• If compromised, all Keys are compromised.
• Single point of failure
• Performance bottleneck.
CA (Certificate Authority):
• Each node keeps its private key.
• The CA certifies (sign) that the public key belong to the node and
everyone trust the CA has checked this fact for each node.
• All public key certificates may be kept in one place or
each node keeps its own certificate and presents it to whoever asks
for it.
• Certificates expire after a reasonable period (e.g., 1 year) but can be
revoked at any time and the CA periodically publishes a CRL
(certificate revocation list) of all the revoked certificates.
• Clients should check the latest CRL before trusting a certificate.
Session Key Establishment
It is a good idea to generate a separate key for each session to use for
encryption/decryption of session data following the session authentication
phase.
Why?
• Keys are kind of "wear out" if used a lot!
The availability of more cipher text, the more likely an intruder may
find the key.
• Prevent replay and decryption of previously recorded message.
•
Delegation
It's not who you are. It's who you're working for
Sometime it is necessary to have some entity act on your behave.
One possible means of allowing this is to give your password to this
entity.
This is not usually a good idea (please never do that! cairo).
The best mechanism to achieve that is
delegation (or authentication forwarding).
Generate a special message, signed by you
(using public key cryptography, or through the use of KDC),
specifying:
• To whom you are delegating the rights,
• Which rights are being delegated &
• For how long.
Authentication of People
User Authentication can be achieved using:
• What you know: e.g., password.
• What you have: e.g., a Physical key.
• What you are: e.g., Biometrics such as
voice/face/eye/fingerprint.
Passwords
Problems:
• Eavesdropping.
• Read stored file.
• Easy to guess on-line.
• Easy to crack off-line.
• Users may write it down.
On-Line Password Guessing
Odd cases:
• Some banks set passwords as the last 4 digits of SSN.
• Some driver’s licenses use SSN as the license number.
• When you write a check at a store, the clerk writes your
driver's license number on the check.
• Thus the clerk may get all the information for your bank
account!
Helpful Tips:
•
•
•
•
•
•
Set limit on the number of trials.
Process incorrect passwords s l o w l y
Report to users of unsuccessful attempts.
Assign users an easy to pronounce strings as passwords.
Do not let users choose easy-to-guess passwords.
Force users to change passwords frequently and prevent them from
using old ones.
Off-Line Password Guessing
Obtaining a hash of a password h, an attacker can guess the password w
and
checks to see if h = MD (w).
If some one obtains a file F containing the hashes of many passwords,
e.g., /etc/passwd he can perform a dictionary attack:
for each word w in dictionary D
do
Compute h = MD (w)
for each e in F
do
if e == h then w is a password
done
done
The number of performed hashes is: |D|
Storing a random number s (salt) and e = MD (w|s)
makes it harder for a dictionary attack:
for each entry <s, e> in F
do
for each word w in the dictionary D
do
Compute h = MD (w|s)
if e == h then w is a password
done
done
The number of performed hashes is: |D|.|F|
How long should a password be?
To protect against on-line attack:
short password is fine.
E.g., ATM systems have 4 digits (10,000
different PIDs),
This it is OK since you only have 3 guesses before
rejecting/capturing your card.
To protect against off-line attack:
64 bits of randomness, number of trials 264 which is
considered computationally hard:
• In decimal this is about 20 digits to remember.
• If we select random characters we need 11 characters.
(upper case, lower case, digits, punctuations)
• If we generate pronounceable passwords we need 16
characters.
(case-insensitive and every third char is one of the
6 vowels)
Eavesdropping
• Low tech: e.g., watch someone type a password.
Protection: use shift/control chars, and don't display the typed chars.
• High-Tech: e.g., wire-tapping, software-based keystroke logging.
Protection: use one-time password list (use new password each time)
&
numbered list of passwords (system asks for one at random).
Passwords & Careless Users
Professor:
Q: "Are there any advantages of passwords over biometric devices?"
Student:
A: "When you want to let someone use your account,
• with password you just give it them,
• while with a biometric device you have to go with them until they are
logged in!"
Users should be educated of the importance of security.
General Tips:
• Do not exchange passwords using email.
• Use different passwords on different systems or accounts.
• Change your password frequently.
• Abort Login Trojan Horses (e.g., type Alt-Ctrl-Del).
Initial Password Distribution:
One popular scheme: generate a pre-expired random password and
hand it to the user.
It must be changed as part of the first login process.
Authentication Tokens:
Physical devices a person carries around and uses in authentication.
People tend to be less willing to "loan" a token to a friend than to share a
password.
Example: Cryptographic calculator:
• Encrypt current time and display the result.
• The user types this number in place of a password.
• The computer does the same (takes into consideration that clocks
drift).
Physical Access:
The location from which access is requested can be part of the
authentication process.
For Example, many bank transactions can only be initiated at teller's
terminals inside the bank.
Biometrics:
Measure physical characteristics and match them against a profile.
Examples:
• Retinal scanner.
• Fingerprint readers.
• Face recognition.
• Iris scanner.
• Voiceprints.
• Keystroke timing.
• Hand signatures.
Security Handshake Protocols
The following is a series of security handshake protocols.
They are presented and evaluated according to:
security & pereformance
The performance parameters are:
• Number of messages,
• Processing power required, and
• Compactness of messages
Login Protocols
Shared Secret
Protocol 1:
{====================================
Alice
Bob
I'm Alice
>
a Challenge R
<
>
f(K, R)
====================================}
f(K, R) : K is a shared secret between Alice and Bob.
f can be either encryption or hash function.
Pitfalls:
An eavesdropper could mount an off-line passwd-guessing attack knowing
both R and f (K,R).
Protocol 2:
{===============================
Alice
Bob
I'm Alice
>
K{R}
<
R
>
===============================}
K{R} is an encryption and not a hash function.
Pitfalls:
• If R is a recognizable quantity
(e.g., a 32-bit random number padded with 32 zero bits to fill out an
encryption block),
Then Trudy, without eavesdropping, may mount a dictionary attack by
sending "I'm Alice" and obtaining K{R}.
• On the other hand, Alice can authenticate Bob by Recognizing the 32 zero
bits of R
• To foil the replaying of K{R} (Trudy impersonate Bob to Alice) use
a timestamp instead of 32 zero bits to fill the encryption block.
Protocol 3 & 4:
{====================================
Alice
Bob
Protocol 3:
I'm Alice, K{timestamp}
>
-----------------------------------------------------------Protocol 4:
I'm Alice, timestamp, hash {K, timestamp}
>
====================================}
These two protocols require both Alice and Bob to have reasonably
synchronized clocks.
Beside saving two messages,
Bob does not need to keep any volatile state (e.g., R).
Pitfalls:
• If Alice using the same K on multiple servers,
Trudy can send the same message to another server as Alice!
• Even if Alice is using K for only one server,
If Trudy can reset back Bob's clock, he can impersonate Alice.
Clock-setting could be serious security vulnerability.
One-way Public Key
In the above four protocols,
Trudy can impersonate Alice if she can read Bob's database.
This can be avoided by using public key technology.
Protocol 5:
{=================================
Alice
Bob
I'm Alice
>
<
R
sign R: [R]Alice
>
==================================}
Pitfalls:
Trudy can trick Alice into signing something she does not know!
Protocol 6:
{================================
Alice
Bob
I'm Alice
>
X<
{R}Alice
sign X: R = [X]Alice
>
=================================}
Pitfalls:
Trudy can trick Alice into decrypting a message sent to Alice by someone else
that he likes to read!
The solution for the above two pitfalls is to make sure that:
R has a known type/structure.
Mutual Authentication
Shared Secret
Protocol 7:
{=================================
Alice
Bob
I'm Alice
>
Rb
<
f(K, Rb)
>
>
Ra
<
f(K, Ra)
=================================}
Protocol 8:
Reduce number of messages in Protocol 7 by
Putting more than one item of information into each message:
{=================================
Alice
Bob
I'm Alice, Ra
>
<
f(K, Ra), Rb
>
f(K, Rb)
=================================}
Pitfall 1: Reflection Attack
Trudy can impersonate Alice to Bob by opening a second connection to Bob
(or to another sever that share the same secret with Alice):
Session1:
{==================================
Trudy
Bob
I'm Alice, Ra
>
<
f(K, Ra), Rb
suspend session 1......
Session 2:
{==============================
Trudy
Bob
I'm Alice, Rb
>
<
f(K, Rb), Rb'
abort session 2.......
continue session 1......
f(K, Rb)
>
=========================== ======}
Possible fix:
Add your name to the encrypted quantity:
{================================
Alice
Bob
I'm Alice, Ra
>
<
f(K, Bob|Ra), Rb
f(K, Alice|Rb)
>
================================}
Why Protocol 7 does not suffer from the reflection attack?
It follows a good security principle:
The initiator should be the first to prove its identity.
Pitfall 2: Passwod guessing
Trudy may mount an off-line password guessing attack:
{======================================
Trudy
Bob
I'm Alice, Ra
>
<
f(K, Ra), Rb
.........
suspend session and use: Ra, and f(K,Ra) to guess K.
======================================}
Protocol 7 does not suffer from such attack (though Trudy can impersonate Bob to
mount such attack,
but it is much more difficult to impersonate Bob than to impersonate Alice).
Protocol 9:
Protocol 7 is very good, since it does not suffer from Reflection and Password
attacks.
We can improve it by reducing the number of messages to 4 instead of 5 as
follows:
{===============================
Alice
Bob
I'm Alice
>
Rb
<
>
f(K, Rb), Ra
<
f(K, Ra)
===============================}
Protocol 10:
We can use time stamps to reduce the number of messages to 2:
{==================================
Alice
Bob
I'm Alice, f(K, timestamp)
>
<
f(K, timestamp++)
==================================}
Two-way Public Key
Protocol 11:
{=================================
Alice
Bob
I'm Alice , Ra
>
<
[Ra]Bob , Rb
>
[Rb]Alice
=================================}
Protocol 12:
{===============================
Alice
Bob
I'm Alice, {Ra}Bob
>
Ra, {Rb}Alice
<
>
Rb
===============================}
Mediated Authentication
KDC operation (in Principle):
{========================================
Alice
KDC
Bob
>
Alice wants Bob
<
Ka {use Kab for Bob}
>
Kb {use Kab for Alice}
=========================================}
KDC operation (in Practice):
{==========================================
Alice
KDC
Bob
>
Alice wants Bob
<
Ka {use Kab for Bob},
ticket to Bob = Kb {use Kab for Alice}
"I'm Alice", ticket to Bob
>
.......... mutual authentication using Kab ...........
=========================================}
Classical Examples of KDC authentication
The Basic Needham-Shroeder Protocol
{========================================
Alice
KDC
Bob
N1, Alice wants Bob
>
<
Ka {N1,"Bob", Kab, ticket to Bob},
where ticket to Bob = Kb {Kab, "Alice"}
ticket to Bob, Kab{N2}
>
<
Kab{N2--, N3}
Kab {N3--}
>
========================================}
• N is a "nonce", a number that is used only once
(e.g., a sequence numer, random number, timestamp).
• N1: to prevent Trudy from impersonating KDC and
replaying old replies to Alice.
• N2 and N3 are challenges for mutual authentication.
The Kerberos Authentication Protocol:
It is based on Needham-Shroered protocol, but is much simpler since it is based on
timestamp and the ticket includes expiration date.
{===============================================
Alice
KDC
Bob
N1, Alice wants Bob
>
<
Ka{N1,"Bob", Kab, ticket to Bob},
where ticket to Bob = Kb {Kab, "Alice", expiration time}
ticket to Bob, Kab{timestamp}
>
<
Kab{timestamp++}
================================================}
Network Authentication Standards: Kerberos
• Kerberos designed at MIT and it is name of a 3 headed dog!
• It is a secret key based service for providing authentication in a
network.
Some applications that use Kerberos: telnet, rsh and NFS.
Master Keys and Session Keys:
• The KDC shares a secret key, called the master key, with each principle
(each user and each resource).
Alice's master key KA is derived from her password.
• The workstation asks the KDC for a limited-lifetime session key SA
The KDC sends the workstation:
KA{SA} and a ticket-granting ticket (TGT) Kkdc {T}
T contains: Alice's name, SA and expiration time.
Kkdc is the he KDC master key.
• The workstation: forgets Alice's KA and remembers SA and the TGT.
This is illustrated as:
{=====================================
Alice
workstation
KDC
>
Alice, passwd
>
Alice needs a TGT
<
KA{SA}, Kkdc {T}
=====================================}
When Alice needs to talk to Bob (e.g., % rsh Bob)
• Her workstation sends the TGT to the KDC.
The KDC generates KAB and send to the workstation:
SA{KAB} & a ticket to Bob = KB{ "Alice", KAB}
• Her workstation sends this ticket to Bob along with an
authenticator KAB {t}
where t is the current time to prove to Bob that she knows KAB
(Kerberos allows up to 5 minutes skew between clocks).
• Bob sends back KAB {t+1} to prove that he is indeed Bob
(since he must knows KB to find out KAB ).
• Thereafter, messages between Alice and Bob may be
encrypted and integrity protected using KAB
This is illustrated as:
{=================================================
Alice
workstation
KDC
Bob
rsh Bob
>
Alice wants Bob, TGT
>
<
SA{"Bob", KAB , ticket to Bob}
>
ticket to Bob = KB{ "Alice", KAB}, KAB {t}
KAB {t+1}
<
=================================================}