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