a practical study and analysis on openssl applicationcomp5351/main/openssl.pdf · a practical study...

A Practical Study and Analysis on OpenSSL Application Internet Infrastructure Security - COMP5351 Dr. Rocky K. C. Chang 27th April 2005 Prepared by: Kunwar Niranjan 02701070g [email protected] Engriwan Wilhelmi 03721472g [email protected] Lo Fuk Kin 04427822g [email protected] Contribution: Chapter 1 (Lo Fuk Kin, Engriwan Wilhelmi) Chapter 2, 3 (Lo Fuk Kin) Chapter 4, 5 (Kunwar Niranjan) Chapter 6 (Engriwan Wilhelmi) Chapter 7 (Engriwan Wilhelmi, Kunwar Niranjan)

2

Abstract The SSL (Secure Socket Layer) and TLS (Transport Layer Security) protocols are used to secure applications that need to communicate over an open network. OpenSSL is an open source implementation of the SSL and TLS protocols, and is by far the most widely deployed, freely available implementation of these protocols. In this project we have analyzed the OpenSSL implementation by observing its flow at packet level. We also capture ten e-banking systems in Hong Kong. Experiments are done to measure the performance of OpenSSL crypto library. We have also analyzed the security of cryptographic algorithms, known vulnerabilities and attacks on OpenSSL.

3

TABLE OF CONTENTS

1. Introduction ............................................................................................................................. 6

2. Obeservation ........................................................................................................................ 8

2.1 Connecting Using SSL Version 2.0 on Port 443 .......................................................................... 8 2.1.1 Client Hello.................................................................................................................................. 10 2.1.2 Server Hello ................................................................................................................................. 10 2.1.3 Client Master Key........................................................................................................................ 11

2.2 Connecting Using SSL Version 3.0 on Port 443 .........................................................................11 2.2.1 Client Hello.................................................................................................................................. 13 2.2.2 Server Hello, Certificate, Server Key Exchange.......................................................................... 14 2.2.3 X.509 Certificate Specification.................................................................................................... 14 2.2.4 Client Key exchange, Change Cipher Specification, Client Finished message ........................... 14 2.2.5 Change Cipher Spec, Server Finished message ........................................................................... 15

2.3 Connect to the web server Using TLS1.0................................................................................... 15

2.4 Mutual Authentication................................................................................................................ 16

2.5 Session Reused ............................................................................................................................. 17

2.6 International Set-up Process (Server Gated Cryptography) ................................................... 17 2.6.1. Client Hello at Set-up process...................................................................................................... 17 2.6.2 Server Hello Messages................................................................................................................. 18 2.6.3 Client Key Exchange, Change cipher spec. ................................................................................. 18 2.6.4 Server Change Cipher Specification ............................................................................................ 19

2.7 Closure Alert................................................................................................................................ 19

2.8 e-Banking Systems in Hong Kong.............................................................................................. 19

3. OpenSSL Implementation .......................................................................................... 21

3.1. SSL and TLS specification .......................................................................................................... 21

3.2. Things currently implemented in SSL....................................................................................... 21

3.3. SHA-256 is not supported by OpenSSL yet............................................................................... 22

4. Security Functions and Performance............................................................................ 23

4.1. Server Benchmarking.................................................................................................................. 24

4.2. Remote connections benchmarking ........................................................................................... 30

4

4.3. Data transfer time comparison................................................................................................... 33

5. Security of Cryptographic Algorithms ........................................................................... 34

5.1 Symmetric Ciphers ...................................................................................................................... 35 5.1.1 Block Ciphers and Stream Ciphers .............................................................................................. 35 5.1.2 Basic block cipher modes ............................................................................................................ 35 5.1.3 EVP API....................................................................................................................................... 36 5.1.4 Ciphers ......................................................................................................................................... 37 5.1.4.1 AES.............................................................................................................................................. 37 5.1.4.2 Blowfish....................................................................................................................................... 38 5.1.4.3 CAST5 ......................................................................................................................................... 39 5.1.4.4 DES.............................................................................................................................................. 40 5.1.4.5 Triple DES ................................................................................................................................... 40 5.1.4.6 IDEA............................................................................................................................................ 41 5.1.4.7 RC2 .............................................................................................................................................. 41 5.1.4.8 RC4 .............................................................................................................................................. 42 5.1.4.9 RC5 .............................................................................................................................................. 43

5.2. Public Key Cryptography and Key Agreement ........................................................................ 44 5.2.1. Diffie-Hellman (DH).................................................................................................................... 44 5.2.2. Digital Signature Algorithm (DSA) ............................................................................................. 45 5.2.3. RSA.............................................................................................................................................. 46

5.3 Certificates ................................................................................................................................... 47 5.3.1 x509 ............................................................................................................................................. 47

5.4 Authentication Codes, Hash Functions ..................................................................................... 48 5.4.1. Hashing with the EVP API........................................................................................................... 50

6. Known Attacks on SSL ....................................................................................................... 52

6.1 Passive attacks ............................................................................................................................. 52 6.1.1 Traffic analysis............................................................................................................................. 53 6.1.2 Chosen-Plaintext .......................................................................................................................... 53

6.2 Active attacks ............................................................................................................................... 55 6.2.1 Cut-and-Paste............................................................................................................................... 55 6.2.2 Short-Block.................................................................................................................................. 56

6.3 Attacks on key exchange protocol .............................................................................................. 57 6.3.1 RSA key exchange and authentication......................................................................................... 58 6.3.2 Diffie-Hellman key exchange with authentication....................................................................... 58 6.3.3 Ciphersuite rollback ..................................................................................................................... 59 6.3.4 Key-exchange algorithm rollback ................................................................................................ 60

5

6.3.5 Version Rollback.......................................................................................................................... 61

6.4 OpenSSL security vulnerabilities ............................................................................................... 61 6.4.1 Denial of Service.......................................................................................................................... 62 6.4.2 Klima-Pokorny-Rosa attacks on RSA in SSL/TLS...................................................................... 63 6.4.3 Timing attacks on RSA ................................................................................................................ 64 6.4.4 Timing attacks on SSL/TLS with CBC encryption...................................................................... 65

7. Conclusions............................................................................................................................ 66

8. References .............................................................................................................................. 67

6

1. Introduction

Cryptography is an essential element in securing communications and applications in public networks. Although it is a cornerstone in a society increasingly reliant on e-commerce, cryptography is a difficult discipline to master and is best left to professional cryptography developers for both algorithm development and implementation. Successful application developers should rely on the tools created by the cryptography professional experts when writing software that uses cryptography.

OpenSSL was developed to provide developers and administrators with a complete and extensive library for all important and frequently used cryptographic algorithms used in today's programs. OpenSSL also provides programs that can be used to implement certification authorities, create private/public key pairs for S/MIME users or SSL servers, etc. These latter topics are beyond the scope of this project.

The principle behind OpenSSL, hence SSL/TLS is the new layer inserted between TCP and application layer:-

Application Layer

Handshake

protocol

Alert protocol Change Cipher

protocol

Record Layer

TCP

IP The SSL protocol itself consists of handshake protocol, alert protocol, change cipher protocol, and record layer. SSL is widely used on the web application to authenticate the server and client where the protocol protects the message’s Confidentiality, Integrity and Authentication.

7

In terms of Confidentiality, the SSL protocol protects message from eavesdropping by encryption using either Symmetric Cryptography (share key) or Public Key Cryptography.

Data integrity is a special calculation method which can have a fixed number of bytes to represent the message, no matter how long the real message is. Recipient can perform the same calculation when received. So recipient can check the whether the message has been alter or modified or not. That is also known as digest algorithm, such as MD5 or SHA-1. Message digest algorithms also need to work with Message Authentication Code or MAC. Authentication is just like a digital signature where certificates are passed between parties. Public key cryptography can be used to digitally sign a message. But, there needs to be a third party to verify the certificates that contain IDs, addresses and public keys. Certification Authority or CA is commonly used to verify the certification information and determine which keys belong to which individuals. In Hong Kong, the trusted CA is Hong Kong Post Office. In the following sections, we analyze SSL’s protocols and layer in detail. As the main objective of this project is to understand how OpenSSL works, we also include a practical analysis on the captured data between a web server and a client and study its protocol weaknesses. The project is divided into five sections. In the next section, a detailed observation on the secure service on port 443 is presented. Here, we use the packet capturing tool called “Ethereal” which is publicly available at no cost. Through the packet observation, we compare the theoretical data with the experimental data and comment the results. In section three, we describe the implementation of OpenSSL and compare its specifications with the ones outlined in the manual. Several real life examples of OpenSSL implementations in e-Banking across Hong Kong are presented. Furthermore, it is widely postulated that the performance of a web server is affected by OpenSSL due to the encryption and decryption processes. Thus, in section four, we observe the performance of a web server with and without SSL. In section five, we analyze different cryptography algorithms supported by OpenSSL. And in section six, several known attacks on SSL protocols as well the recent attacks on OpenSSL are presented.

8

2. Obeservation

The observation starts by capturing the packets using Ethereal. In this experiment, the OpenSSL software is installed on an Apache web server. Basically, the SSL connection between a client and a server can be described as in the following:-

2.1 Connecting Using SSL Version 2.0 on Port 443

The following command shows the response received by the client when connecting to the server. Here, the server host name is web.hkisl.net and the client is connected to its port number 443. OpenSSL> s_client -ssl2 -connect web.hkisl.net:443

CONNECTED(00000003)

depth=0

/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/[email protected]

verify error:num=18:self signed certificate

verify return:1

depth=0


verify return:1

9

---

Server certificate

-----BEGIN CERTIFICATE-----

MIIEDDCCA3WgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBuzELMAkGA1UEBhMCLS0x

EjAQBgNVBAgTCVNvbWVTdGF0ZTERMA8GA1UEBxMIU29tZUNpdHkxGTAXBgNVBAoT

EFNvbWVPcmdhbml6YXRpb24xHzAdBgNVBAsTFlNvbWVPcmdhbml6YXRpb25hbFVu

aXQxHjAcBgNVBAMTFWxvY2FsaG9zdC5sb2NhbGRvbWFpbjEpMCcGCSqGSIb3DQEJ

ARYacm9vdEBsb2NhbGhvc3QubG9jYWxkb21haW4wHhcNMDUwMzAxMTAzMTU0WhcN

MDYwMzAxMTAzMTU0WjCBuzELMAkGA1UEBhMCLS0xEjAQBgNVBAgTCVNvbWVTdGF0

ZTERMA8GA1UEBxMIU29tZUNpdHkxGTAXBgNVBAoTEFNvbWVPcmdhbml6YXRpb24x

HzAdBgNVBAsTFlNvbWVPcmdhbml6YXRpb25hbFVuaXQxHjAcBgNVBAMTFWxvY2Fs

aG9zdC5sb2NhbGRvbWFpbjEpMCcGCSqGSIb3DQEJARYacm9vdEBsb2NhbGhvc3Qu

bG9jYWxkb21haW4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL7m7N0prcu2

UBMyuCSqhrzjVJhCj0snQaYf/HZkkCFo+/Xdqn1X8ARqaR9E9gw+p34IS/zm2abu

yU3SpB14xUcKGGH2HMTEzZ8EBeoPnLByuqOangCXWNVz8H2qWIP8I+lWWKZL6lcL

yxkB3YbTYUGYqNA9ri5lnS0AzkoAriibAgMBAAGjggEcMIIBGDAdBgNVHQ4EFgQU

lihcUcJuzu46jPiGbnf28GBmZ6swgegGA1UdIwSB4DCB3YAUlihcUcJuzu46jPiG

bnf28GBmZ6uhgcGkgb4wgbsxCzAJBgNVBAYTAi0tMRIwEAYDVQQIEwlTb21lU3Rh

dGUxETAPBgNVBAcTCFNvbWVDaXR5MRkwFwYDVQQKExBTb21lT3JnYW5pemF0aW9u

MR8wHQYDVQQLExZTb21lT3JnYW5pemF0aW9uYWxVbml0MR4wHAYDVQQDExVsb2Nh

bGhvc3QubG9jYWxkb21haW4xKTAnBgkqhkiG9w0BCQEWGnJvb3RAbG9jYWxob3N0

LmxvY2FsZG9tYWluggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEA

AU5Dy9RORAwT3gBvbnYv2sI4Oi3M1S69QhiTqEPx75b5jmVNSv6yTSXasbZcWt1y

v6VkDgcP+WX2LinxX3x39RXEKYyIr6B1CH48Gzk/ajN9T7YcIpAL4ZmtYK2/CwNq

WvHgsdaL/nrYdjw9E1H2UwkEWpihPoKNAlRGChlaWoI=

-----END CERTIFICATE-----

subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/[email protected]

domain

issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/[email protected]

omain

---

No client certificate CA names sent

---

Ciphers common between both SSL endpoints:

RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5

EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5

RC4-64-MD5

---

SSL handshake has read 1176 bytes and written 239 bytes

10

---

New, SSLv2, Cipher is DES-CBC3-MD5

Server public key is 1024 bit

SSL-Session:

Protocol : SSLv2

Cipher : DES-CBC3-MD5

Session-ID: BE185FA2BBC316B70420B1D549E5B6DF

Session-ID-ctx:

Master-Key: 7C47609D895516B20E184FBE3755EF41C30BCADCCD73942F

Key-Arg : FBD4BA1BC7F61428

Krb5 Principal: None

Start Time: 1113967285

Timeout : 300 (sec)

Verify return code: 18 (self signed certificate)

2.1.1 Client Hello

The first message received by the server is Client Hello message which contains the Handshake type is (1) and includes the random number 16 bytes generated by the client. The client also informs the server how many Cipher Suites it can support. In this case, the client can support 7 different kinds of cipher suites.

2.1.2 Server Hello

The server responds by sending out a 16 bytes connection ID and informs the client which Cipher

11

suite it chooses. The server also confirms that it is using an SSL version 2.0 protocol and sends out its own certificate to the client.

2.1.3 Client Master Key

Client sends the key exchange to Server. After that Both parties can use the encrypted channel to send and receive data.

2.2 Connecting Using SSL Version 3.0 on Port 443

As shown in the following screen capture, the timeout is 7200 seconds for SSL version 3.0.

12

[root@flo root]# openssl s_client -ssl3 -connect web.hkisl.net:443

CONNECTED(00000003)

depth=0


verify error:num=18:self signed certificate

verify return:1

depth=0


verify return:1

---

Certificate chain

0

s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/[email protected]

i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/[email protected]

---

Server certificate


MIIEDDCCA3WgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBuzELMAkGA1UEBhMCLS0x

EjAQBgNVBAgTCVNvbWVTdGF0ZTERMA8GA1UEBxMIU29tZUNpdHkxGTAXBgNVBAoT

EFNvbWVPcmdhbml6YXRpb24xHzAdBgNVBAsTFlNvbWVPcmdhbml6YXRpb25hbFVu

aXQxHjAcBgNVBAMTFWxvY2FsaG9zdC5sb2NhbGRvbWFpbjEpMCcGCSqGSIb3DQEJ

ARYacm9vdEBsb2NhbGhvc3QubG9jYWxkb21haW4wHhcNMDUwMzAxMTAzMTU0WhcN

MDYwMzAxMTAzMTU0WjCBuzELMAkGA1UEBhMCLS0xEjAQBgNVBAgTCVNvbWVTdGF0

ZTERMA8GA1UEBxMIU29tZUNpdHkxGTAXBgNVBAoTEFNvbWVPcmdhbml6YXRpb24x

HzAdBgNVBAsTFlNvbWVPcmdhbml6YXRpb25hbFVuaXQxHjAcBgNVBAMTFWxvY2Fs

aG9zdC5sb2NhbGRvbWFpbjEpMCcGCSqGSIb3DQEJARYacm9vdEBsb2NhbGhvc3Qu

bG9jYWxkb21haW4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL7m7N0prcu2

UBMyuCSqhrzjVJhCj0snQaYf/HZkkCFo+/Xdqn1X8ARqaR9E9gw+p34IS/zm2abu

yU3SpB14xUcKGGH2HMTEzZ8EBeoPnLByuqOangCXWNVz8H2qWIP8I+lWWKZL6lcL

yxkB3YbTYUGYqNA9ri5lnS0AzkoAriibAgMBAAGjggEcMIIBGDAdBgNVHQ4EFgQU

lihcUcJuzu46jPiGbnf28GBmZ6swgegGA1UdIwSB4DCB3YAUlihcUcJuzu46jPiG

bnf28GBmZ6uhgcGkgb4wgbsxCzAJBgNVBAYTAi0tMRIwEAYDVQQIEwlTb21lU3Rh

dGUxETAPBgNVBAcTCFNvbWVDaXR5MRkwFwYDVQQKExBTb21lT3JnYW5pemF0aW9u

MR8wHQYDVQQLExZTb21lT3JnYW5pemF0aW9uYWxVbml0MR4wHAYDVQQDExVsb2Nh

bGhvc3QubG9jYWxkb21haW4xKTAnBgkqhkiG9w0BCQEWGnJvb3RAbG9jYWxob3N0

LmxvY2FsZG9tYWluggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEA

AU5Dy9RORAwT3gBvbnYv2sI4Oi3M1S69QhiTqEPx75b5jmVNSv6yTSXasbZcWt1y

v6VkDgcP+WX2LinxX3x39RXEKYyIr6B1CH48Gzk/ajN9T7YcIpAL4ZmtYK2/CwNq

13

WvHgsdaL/nrYdjw9E1H2UwkEWpihPoKNAlRGChlaWoI=


subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/[email protected]

domain

issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/[email protected]

omain

---

No client certificate CA names sent

---

SSL handshake has read 1620 bytes and written 314 bytes

---

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 1024 bit

SSL-Session:

Protocol : SSLv3

Cipher : DHE-RSA-AES256-SHA

Session-ID: 6217CF676AA15B9BD1A03062750F23F61BEF01265D4BF9C2BFFC7CB797516B3E

Session-ID-ctx:

Master-Key: 96CC94D2451579417AEA8093CDDED63D0A40E200163D3D08FA22A08E858E23AFA5FCC3086FC6D93264CD15B7B2710F44

Key-Arg : None

Krb5 Principal: None

Start Time: 1113967921

Timeout : 7200 (sec)

Verify return code: 18 (self signed certificate)

2.2.1 Client Hello The client informs the server that the highest SSL version it can support is 3.0. It also provides a random number 32 bytes and a Session ID which usually starts from 0 for a new session. The compression method is null.

14

2.2.2 Server Hello, Certificate, Server Key Exchange From our observation, we found that the timeout is 300 seconds when using SSL version 2.0 and 7200 seconds for SSL version 3.0. In its Handshake protocol, SSL version 2.0 can send multiple messages to the client. In type number 2, the random number sent is 32 bytes where the first four bytes is the GMT_Unix _time and the others 28 bytes are random numbers generated by the server. Certificate sent by the server follows the X.509 specification. When sending out the session ID, the compression method is not used which is null. 2.2.3 X.509 Certificate Specification Server certificate


Version

Serial Number

Algorithm Identifer

Issuer

Period of validity

Subject

Subject’s Public Key

Issuer Unique ID

Subject Unique ID

Extension

Signature


So the server private-public key pairs can be self generated in the openSSL.

2.2.4 Client Key exchange, Change Cipher Specification, Client Finished message Change the pending status to active status, and test the cipher suite with the finished message. Finished Message was added in SSL3.0.

15

2.2.5 Change Cipher Spec, Server Finished message Similar process is observed when the client changes its pending status to active status. The cipher suite is tested in the finished message. Finished message was added in SSL3.0. 2.3 Connect to the web server Using TLS1.0 For TLS version 1.0, the version is changed to 3.01 (0x0301)..

Client Hello message includes the handshake protocol version which is 01 (0x0301) meaning it is using TLS 1.0. If the second byte data shows 00 (0x0300), the server is using SSL version 3.0. The Random Number generated is 32 bytes (first four bytes is contributed by the Unix time and the last 28 bytes is generated from the server). Less cipher suites are on the list of the Hello message because of the US export law issue.

16

2.4 Mutual Authentication If both parties have certificates from trusted CAs, then the two parties can prove their identities. This is known as mutual authentication. Mutual authentication using SSL protocol is described below:

Before a mutual authentication can occur, the parties involved must first trust the CAs that signed each other's certificates. In practice, this means that they must have copies of the CAs' certificates--which contain the CAs' public keys--and that they must trust that these certificates really belong to the CAs. To mutually authenticate, the Server establishes a connection to the Client. To start the authentication process, Server gives certificate to Client. The certificate tells Client who Server is claiming to be (the identity), what Server's public key is, and what CA is being used to certify the certificate. Client will first make sure that the certificate is valid by checking the CA's digital signature to make sure that the CA actually signed the certificate and that the certificate hasn't been tampered with. (This is where Client must trust the CA that signed Server's certificate.)

Once Client has checked out Server's certificate, Client must make sure that Sever really is the one identified in the certificate. Client generates a random message and sends it to Server, asking Server to encrypt it. Sever encrypts the message using his private key, and sends it back to Client. Client decrypts the message using Server's public key. If this results in the original random message, then Client knows that Sever is who claim to be. Now that Client trusts Server's identity, the same operation must happen in reverse. Client sends his certificate to Server, Server validates the certificate and sends a challenge message to be encrypted. Client encrypts the message and sends it back to Sever, and Sever decrypts it and compares it with the original. If it matches, then Server knows that Client is who claim to be. At this point, Server and Client have established a connection to each other and are certain that they know each others' identities.

17

2.5 Session Reused Basically, the Reused session ID is more efficient in the negotiation process. However, the authentication process is omitted. Our observation shows that the server sometimes continues to send the certificate to client even in a reused case.

2.6 International Set-up Process (Server Gated Cryptography)

In Netscape browser, the server gated cryptography for Internet Explorer is called International Set-Up. 2.6.1. Client Hello at Set-up process At first, the client sends a lower version in its Client Hello message.

18

2.6.2 Server Hello Messages

For server Hello message, the Handshake type is 2. Once the server knows the client can support version 3, it chooses the highest version (in this case version 3.0) for subsequent message exchanges. Random Number is selected at the server side like nonce where it serves as a seed of other key component. While Certificate is sent out in the https:// sites allowing users to authenticate the server site, the Server Key Exchange in the cipher Suite field indicates the cryptography algorithm and key size is chosen { In that example Cipher suite is TLS_RSA_WITH_RC4_128_MD4 (option 4) }. The ServerHelloDone informs the client that the server has finished the negotiation message.

2.6.3 Client Key Exchange, Change cipher spec.

Following the Server Hello messages, the client and server can move to the next phase to establish secret communication by using the Cipher suite agreed by both parties previously.

19

2.6.4 Server Change Cipher Specification

After the secret communication is established, the application data can be transmitted over the same channel. 2.7 Closure Alert

It can be initialed by either parties to end the secure session. It also prevents information leakage to attacker. It will also refuse the other parties to use the weaker encryption Algorithm.

2.8 e-Banking Systems in Hong Kong

In this section, we observe packets captured from ten e-banking systems by decreasing the key bits. Only SSL3’s (56 bit and 40 bit) six cipher suites are enabled for this experiment. And we observe how those sites response. Nearly most of the sites can successfully create the SSL session and it will further control in the application whether let the user go into the logon page or require user to upgrade their browser. For complete observation, refer to the web site http://www.geocities.com/franco_lfk/.

20

Summary results from several e-banking systems in Hong Kong. SSL2, TLS and cipher suites that use 128 bit or higher are disabled.

Bank Name Allow /

Refuse to go

into the login

page

Cipher Suite chosen by Server Code ID Bit

Hong Kong Shanghai Bank

Corp.

Refuse TLS_RSA_EXPORT_with_RC4_40_MD5 0003 40

Standard Chartered Bank Refuse TLS_RSA_with_DES_CBC_SHA 0009 56

Hang Seng Bank Refuse TLS_RSA_EXPORT_with_RC4_40_MD5 0003 40

Bank of China Allow TLS_RSA_EXPORT_with_RC4_40_MD5 0003 40

Citi Bank Handshake

Failure

Bank of America Allow TLS_RSA_EXPORT_with_RC4_40_MD5 0003 40

East Asia Bank Refuse SSL_RSA_FIPS_with_DES_CBC_SHA 0fefe 56

DBS Allow TLS_RSA_with_DES_CBC_SHA 0009 56

Bank of Communication Allow TLS_RSA_EXPORT_with_RC4_40_MD5 0003 40

United Bank of Switzerland Refuse TLS_RSA_EXPORT_with_RC4_40_MD5 0003 40

In most cases, SSL3 session is successfully created, except for CitiBank where it fails to

complete the handshake protocol since it rejects the Cipher Suites. Other e-banking systems allow establishing SSL sessions with weaker Cipher suites. However, the Application Layer will decide whether to let users logon or refuse them. (Ethereal captures also attached in the web page directory)

If we enable the 128 bit cipher suites all the e-banking system can let the user go into the login page. The future authentication will control by the applications. One interesting thing is UBS is not only use the login ID and password to authenticate user. User need to type in the third parameter is SecureID. (Attached all the login pages for reference)

21

3. OpenSSL Implementation

Security issues never end. Engineers continuously strengthen the Cipher suites (update libraries) and the some cipher suites are waiting to be implemented. SSL2.0 is not advised to be used, because of the random number is only 16 bytes and does not have the finished message to verify before the change cipher specification message.

3.1. SSL and TLS specification

ClientHello TLS1.0 protocol use a different version number value 3.1 instead of SSL is 3.0

11 Alert Messages were added in the TLS1.0 protocol. Number of TLS1.0 ‘s Cipher suites is less than the SSL3.0 because the export law of the

State. But there will be more at TLS1.1, which is not released yet. TLS does not include the Fortezza_DMS_ Key exchange. Slight different calculation Hash on the finished message as well. TLS includes both

MD5 and SHA-1 in the calculation. Finished Message added in SSL3.0 to ensure that Change cipher Message arrived before

the Finished Message against attack. The TLS1.1 specification is still not complete. So there is many proposed standard and information

which is implemented, and still waiting for putting back to the specification.

3.2. Things currently implemented in SSL

These are documents that describe things that are implemented (in whole or at least great parts) in OpenSSL. It can be found in the directory of openssl-0.9.7g/doc.

Message-Digest Algorithm MD2 and MD5 have been implemented in 1992, and TLS Protocol Version 1.0 (3.1) was proposed on 1999. AS we know they are not compatible with each other. It supposes to replace the SSL 3.0 and others, but SSL 3.0 still dominates the current market nowadays. X.509 Internet Public Key Infrastructure was also implemented as an Online Certificate Status Protocol in the middle of 1999.

Adding Kerberos Cipher Suites to Transport Layer Security (TLS), which proposed on October 1999. Implement Secure Hash Algorithm 1 (SHA1) on September 2001, and Advanced Encryption Standard (AES) Cipher suites for Transport Layer Security (TLS) was proposed on June 2002. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

22

was proposed in 2002(RFC2459). Lastly Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 was implemented on February 2003 (Obsoletes RFC2437).

3.3. SHA-256 is not supported by OpenSSL yet

The reason it's not there now is neither Windows CAPI nor OpenSSL supported -256 or -512 when the hashing functions were first implemented. The development branch of OpenSSL now includes SHA-256/512 so we might look at compiling up 0.9.8-dev (Current version is 0.9.7g).

The code to trigger this bug is as follows:

char *buffer;

SHA256_CTX ctx;

buffer = malloc(1000000);

memset(buffer, 'A', 1000000);

SHA256_Init(&ctx);

SHA256_Update(&ctx, buffer, 1000000);

[root@redhat9-vm] ./s256

Segmentation fault

Valgrind reports the following errors:

==14789== Invalid read of size 4

==14789== at 0x804A187: sha256_block (sha256.c:266)

==14789== by 0xB5FD147C: ???

==14789== Address 0x1BB442A8 is not stack'd, malloc'd or (recently) free'd

==14789==

==14789== Invalid read of size 4

==14789== at 0x804A258: sha256_block (sha256.c:267)

==14789== by 0xB5FD147C: ???

==14789== Address 0x1BB442AC is not stack'd, malloc'd or (recently) free'd

23

4. Security Functions and Performance

As security becomes an integral feature of Internet applications and the use of SSL rises, its impact on the performance of the servers as well the clients is becoming increasingly important. In the paper 1 authors have done a detailed analysis of TLS/SSL protocol with an eye on performance. In this project we have done some experiments of our own to find out the performance of OpenSSL. Testing Environment

Figure 4.1 Testing Network Setup

24

4.1. Server Benchmarking

The OpenSSL developers have built a benchmarking suite directly into the openssl binary. It's accessible via the speed option. It tests how many operations it can perform in a given time, rather than how long it takes to perform a given number of operations. There are three sets of results; e.g. the first line of output shows that within 3 seconds it can perform 372711 md2 operations for 16 byte sized blocks. The second set reports the performance of an algorithm in terms of how many bytes per second it can do the operation for different algorithms with different block size. The last one reports the times needed for sign/verify cycles. Excerpt of the output of openssl speed on our testing server is listed in Figure 4.2.1

Figure 4.2.1 Excerpt from output of openssl speed The full result of openssl speed command is listed below: [root@web niranjan]# openssl speed

Doing md2 for 3s on 16 size blocks: 372711 md2's in 3.00s













[root@web niranjan]# openssl speed


:

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes

md2 1987.79k 4258.94k 5969.51k 6622.21k 6843.05k

:

:

sign verify sign/s verify/s

rsa 512 bits 0.0008s 0.0001s 1260.7 14040.8

25



Doing hmac(md5) for 3s on 16 size blocks: 1773766 hmac(md5)'s in 2.99s





Doing sha1 for 3s on 16 size blocks: 2991527 sha1's in 3.00s





Doing rmd160 for 3s on 16 size blocks: 2564621 rmd160's in 3.01s





Doing rc4 for 3s on 16 size blocks: 18633713 rc4's in 3.00s





Doing des cbc for 3s on 16 size blocks: 11531383 des cbc's in 2.99s





Doing des ede3 for 3s on 16 size blocks: 4204949 des ede3's in 3.00s





Doing aes-128 cbc for 3s on 16 size blocks: 10483957 aes-128 cbc's in 3.01s







26









Doing rc2 cbc for 3s on 16 size blocks: 4316384 rc2 cbc's in 3.00s





Doing blowfish cbc for 3s on 16 size blocks: 19154649 blowfish cbc's in 3.01s





Doing cast cbc for 3s on 16 size blocks: 9059341 cast cbc's in 3.00s





Doing 512 bit private rsa's for 10s: 12594 512 bit private RSA's in 9.99s

Doing 512 bit public rsa's for 10s: 140548 512 bit public RSA's in 10.01s







Doing 512 bit sign dsa's for 10s: 14970 512 bit DSA signs in 9.98s

Doing 512 bit verify dsa's for 10s: 12719 512 bit DSA verify in 10.01s





OpenSSL 0.9.7a Feb 19 2003

built on: Sat Mar 20 11:06:43 CST 2004

27

options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx)

compiler: gcc -fPIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H

-DKRB5_MIT -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_EC

-I/usr/kerberos/include -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -march=i686 -Wa,--noexecstack -DSHA1_ASM

-DMD5_ASM -DRMD160_ASM

available timing options: TIMES TIMEB HZ=100 [sysconf value]

timing function used: times

The 'numbers' are in 1000s of bytes per second processed.

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes

md2 1987.79k 4258.94k 5969.51k 6622.21k 6843.05k

mdc2 0.00 0.00 0.00 0.00 0.00

md4 18296.47k 64906.77k 177231.96k 366831.27k 531901.90k

md5 17050.15k 60999.13k 185812.28k 381381.63k 550461.44k

hmac(md5) 9491.72k 35942.76k 121783.21k 301897.05k 525425.63k

sha1 15954.81k 51627.58k 134607.37k 232928.26k 296635.05k

rmd160 13632.54k 43247.15k 102520.49k 157401.09k 187637.90k

rc4 99379.80k 117382.10k 121888.74k 123810.82k 124258.99k

des cbc 61706.40k 64253.67k 64755.29k 65027.41k 64784.84k

des ede3 22426.39k 22701.46k 22934.18k 22909.95k 22882.99k

idea cbc 0.00 0.00 0.00 0.00 0.00

rc2 cbc 23020.71k 25345.41k 25709.25k 25758.38k 25788.42k

rc5-32/12 cbc 0.00 0.00 0.00 0.00 0.00

blowfish cbc 101818.73k 108847.10k 110094.59k 111068.84k 110912.56k

cast cbc 48316.49k 57794.52k 60380.19k 60449.79k 60757.33k

aes-128 cbc 55728.68k 56263.45k 57177.69k 57414.66k 57702.91k

aes-192 cbc 48877.79k 49763.09k 51688.50k 50413.57k 50408.11k

aes-256 cbc 43785.03k 44470.42k 44960.09k 44892.16k 44930.81k


rsa 512 bits 0.0008s 0.0001s 1260.7 14040.8

rsa 1024 bits 0.0040s 0.0002s 249.7 4727.4

rsa 2048 bits 0.0246s 0.0007s 40.7 1420.9

rsa 4096 bits 0.1627s 0.0025s 6.1 397.1


dsa 512 bits 0.0007s 0.0008s 1500.0 1270.6

dsa 1024 bits 0.0020s 0.0025s 495.6 406.6

dsa 2048 bits 0.0067s 0.0082s 148.5 122.1

28

0

50

100

150

200

250

300

350

400

450

16 bytes 64 bytes 256 bytes 1024 bytes

Block Size

Enc

rypt

ion/

Dec

pryt

ion

(Mbp

s)

md5

hmac(md5)

sha1

Figure 4.2.2 Message Digest Generation/Verification performance

0

20

40

60

80

100

120

140

16 bytes 64 bytes 256 bytes 1024 bytes

block size

Enc

rypt

ion/

Dec

pryt

ion

(Mbp

s)

aes-256

3des

rc4

Figure 4.2.3 Encryption/Decryption performance Figure 4.2.2 shows the performance of the message digest generation and verification algorithms. By default all web browsers use MD5 as the message digest algorithm. Browsers can also be configured to use HMAC(MD5) and SHA1 which are considered to be more secure. As the figure shows, MD5 can generate/verify message digest at a rate of 17Mbps for the message block of 16 bytes and at

29

more than 380Mbps for messages of block size 1024 bytes and more. SHA1 performs slightly better than HMAC(MD5). Form our result it is clear that MD5 is the best performing algorithm. The typical web transfers are about 4 Kbyte or more. So, form the results in Figure 4.2.2 it is evident that generation and verification of message digests is clearly not the bottleneck in TLS. Figure 4.2.3 shows the performance of RC4, 3DES, and AES-256 for different data block sizes. Most web browsers are by default configured to use RC4 for data encryption. When higher level of security is required, 3DES is preferred. For the highest level of security, AES-256 is the recommended encryption algorithm. When RC4 is used as the encryption/decryption algorithm, the server can encrypt/decrypt more than 99Mbps. The encryption rate for AES-256 is between 43- 44Mbps and is based on the block size. With 3DES the encryption/decryption rate goes down to about 22-23Mbps. The results in Figure 4.2.3 shows the fact that encryption/decryption is only small part of the overhead in TLS, it also shows that as the block size increases so does the performance fro RC4 but the performance improvement due to increase in data block size for 3DES and AES-256 is almost flat even with the increase in block size..

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

512bits 1024bits

tim

e(m

s)

sign

verify

Figure 4.2.4 RSA sign/verify cycle

Figure 4.2.4 shows the performance of RSA sign/verify cycle with different keys. We can see from the figure that as the key size doubles from 512bits to 1024bits the signing time increases 5 times and verification time doubles. We also observed that singing takes longer time than verification this is because in practical applications, it is common to choose a small public exponent for the public key. In fact, entire groups of users can use the same public exponent, each with a different modulus.

30

(There are some restrictions on the prime factors of the modulus when the public exponent is fixed.) This makes encryption faster than decryption and verification faster than signing. With the typical modular exponentiation algorithms used to implement the RSA algorithm, public key operations take O(k2) steps, private key operations take O(k3) steps, and key generation takes O(k4) steps, where k is the number of bits in the modulus.2

4.2. Remote connections benchmarking

The s_time option in OpenSSL lets you test connection performance. The most simple invocation will run for 30 seconds, use any cipher, and use SSL handshaking to determine number of connections per second, using both new and reused sessions. To perform this set of experiments we have used the Linux Client with OpenSSL and the Linux Server with OpenSSL. All of the command lines are executed in Linux Client. The figures listed below show the testing of remote SSL connection and retrieving of remote files of different sizes as following:

- Figure 4.3.1 OpenSSL Connection performances with new and reused session. No data is transferred

- Figure 4.3.2 OpenSSL performance downloading 510K file with new and reused session - Figure 4.3.3 OpenSSL performance downloading 1.5MB file with new and reused

session - Figure 4.3.4 OpenSSL performance downloading 11MB file with new and reused session

Figure 4.3.1 OpenSSL Connection performances with new and reused session

[root@ldap niranjan]# openssl s_time -connect 192.168.100.214:443 -ssl3 -cipher DHE-RSA-AES256-SHA

Collecting connection statistics for 30 seconds

33333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333

287 connections in 21.78s; 13.18 connections/user sec, bytes read 0

287 connections in 31 real seconds, 0 bytes read per connection

Now timing with session id reuse.

starting

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr



31

Figure 4.3.2 OpenSSL performance downloading 510K file with new and reused session

Figure 4.3.3 OpenSSL performance downloading 1.5MB file with new and reused session

[root@ldap niranjan ]# openssl s_time -connect 192.168.100.215:443 -www /download/memprof.exe -new

-ssl3 -cipher DHE-RSA-AES256-SHA


3333333333333333333333333333333333333333333333333333



[root@ldap niranjan ]# openssl s_time -connect 192.168.100.215:443 -www /download/memprof.exe -reuse



starting

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr



[root@ldap niranjan ]# openssl s_time -connect 192.168.100.215:443 -www /download/splint.exe -new -ssl3

-cipher DHE-RSA-AES256-SHA


33333333333333333333



[root@ldap niranjan ]# openssl s_time -connect 192.168.100.215:443 -www /download/splint.exe -reuse -ssl3

-cipher DHE-RSA-AES256-SHA


starting

rrrrrrrrrrrrrrrrrrrrrr



32

Figure 4.3.4 OpenSSL performance downloading 11MB file with new and reused session The result of the OpenSSL remote connection test by downloading different file size using new connection and reused session are summarized in Table 4.3.1 Table 4.3.1 The OpenSSL remote connection benchmark data Data Size(MB) Connections(Normal) Connections(Reuse) Time(Normal) Time(Reuse)0 287 9024 31 31 0.5 52 60 31 31 1.5 20 22 31 32 11 3 4 31 41

0

10

20

30

40

50

60

70

510KB 1.5MB 11MB

File size

No. o

f SSL

connec

tions

SSLconnections(Normal)

SSL Connection(session reuse)

Figure 4.3.5 SSL Connections with and without session reuse

[root@ldap niranjan ]# openssl s_time -connect 192.168.100.215:443 -www /download/fp50.linux.tar.gz -new



333



[root@ldap niranjan ]# openssl s_time -connect 192.168.100.215:443 -www /download/fp50.linux.tar.gz

-reuse -ssl3 -cipher DHE-RSA-AES256-SHA


starting

rrrr



33

Figure 4.3.5 shows the number of SSL connections that can be made from the client to the server in order to download different sized files using normal SSL connection and SSL connection with session reuse. We observed that the client can download 52 copies of 510KB file at 31 seconds and 60 copies of the same file can be downloaded by utilizing session id reuse at the same time. Whereas when the file size was 11MB the difference in download copy was just one i.e with normal SSL connection it could download 3 copies of the file whereas with session id reuse it could download just 4 copies. From this set of experiments it is clear that the session id reuse is more useful to use when the object size to be transferred is less than a MB, which is the case in typical web transaction.

4.3. Data transfer time comparison

Since the built in command line utility openssl did not allow us to test how much time it takes to download a particular sized file with only one connection, so we’ve performed a different set of test with the same file size. In this test we have used the Windows Client with a Firebox browser to browse and download files from the Linux Server with OpenSSL. The download time is recorded by capturing the packets in Windows Client using Ethereal with Pcap. This test outlines the time taken to download the files using HTTP and HTTPS. Session establishment (hand-shaking): HTTP: 0.000776seconds HTTPS: 0.0772 seconds

Table 4.4.1 Download Time Data Download Time (Seconds) Data Size HTTP HTTPS(Normal) 510KB 1.13 1.77 1.5MB 3.31 4.79 11MB 23.86 36.92

34

Download Time

0

10

20

30

40

510KB 1.5MB 11MB

File size

Tim

e(se

c)

HTTP

HTTPS

Figure 4.4.1 Download time Figure 4.4.1 shows the time in seconds it takes to download different sized files using normal HPTP and HTTPS. It is evident from the figure that as the size of the file increases the difference in time to download the same file with HTTP and HTTPS increases.

5. Security of Cryptographic Algorithms

The OpenSSL crypto library implements a wide range of cryptographic algorithms used in various Internet standards. The services provided by this library are used by the OpenSSL implementations of SSL, TLS and S/MIME, and they have also been used to implement SSH, OpenPGP, and other cryptographic standards.

libcrypto consists of a number of sub-libraries that implement the individual algorithms. The functionality includes symmetric encryption, public key cryptography and key agreement, certificate handling, cryptographic hash functions and a cryptographic pseudo-random number generator.3 In this section we will be analyzing the security of the cryptographic algorithms implemented in OpenSSL. It is not within the scope of this project to describe the details of how each algorithms work. But in order to analyze and understand the security issues we will describe how each algorithms works at very high level with main focus on security.

35

5.1 Symmetric Ciphers

5.1.1 Block Ciphers and Stream Ciphers

Both block ciphers and stream ciphers would be unable to provide us perfect security, in which an attacker can never recover a message as long as the communicating parties use the algorithm properly. For each type of cipher, the security is, at best, a function of the key length. It's always possible to launch a brute-force attack, in which the attacker tries every possible key until the message properly decrypts. If the key length is long enough, the attack will take so long on average as to be infeasible in practice. Even if there was no better attack on an individual cipher than brute force, there are other issues that plague naive use of both types of cipher. Stream ciphers have the problem that a one-bit flip of the ciphertext causes a one-bit flip in the decrypted plaintext. Obviously, stream ciphers need to be supplemented with data integrity checks. For such purposes, message authentication codes are recommended. When used directly, block ciphers always encrypt a given block of data in the same way, and thus do not effectively conceal patterns in a stream of data. An attacker can keep a dictionary of known plaintext blocks to known ciphertext blocks, which can often be useful in deciphering real messages. Additionally, an attacker can easily substitute one ciphertext block for another, often with great success. There are ways to use ciphers that can solve these problems to some degree, which we discuss in the next section. Additionally, MACs can be used to thwart actual modification attacks. Stream ciphers are subject to a similar, more serious problem. Once you start encrypting using a given key, you must continue to generate new data in the keystream, or generate and exchange a new key. If you start over using the same key, the security of the stream cipher is effectively lost. The solution is to never reuse keys when using a stream cipher. Don't even use the same key across reboots.4

5.1.2 Basic block cipher modes

OpenSSL implements four common modes for block ciphers. Each of these modes can be used with every block cipher in the library. ECB (Electronic Code Book) mode is the basic mode of operation, in which the cipher takes a single block of plaintext and produces a single block of ciphertext. Data streams are broken into blocks that are individually processed. Usually, this mode is padded to accommodate messages that aren't a

36

multiple of the cipher's block size length. Because of padding, the ciphertext can be up to a block longer than the plaintext. In addition, as previously mentioned, this mode is highly susceptible to dictionary attacks. ECB is almost always the wrong mode for the job, because it is so difficult to use securely. It is not recommend using this mode under any circumstances, unless you really know what you're doing. The biggest advantage of ECB over the other common modes is that messages can be encrypted in parallel. However, this is not an adequate reason to use ECB—an alternative mode that allows for parallelization is counter mode, will be discussed later. CBC (Cipher Block Chaining) mode essentially solves ECB's dictionary problem by XORing the ciphertext of one block with the plaintext of the next block. Since block ciphertexts are interdependent, parallelization isn't possible. CBC is still a block-based mode, meaning that padding is generally used. CBC mode can be used to encrypt multiple data streams. However, dictionary attacks are possible if the data streams have common beginning sequences. For that reason, it is possible to set an initialization vector (IV), which is a block of data that gets XOR'd with the first block of plaintext before encrypting that block. The value of the IV need not be secret, but it should be random. The IV must be available to properly decrypt the ciphertext. CFB (Cipher Feedback) mode is one way of turning a block cipher into a stream cipher, though a complete block of plaintext must be received before encryption can begin. This mode isn't as prone to data manipulation attacks as most stream ciphers. Like CBC mode, CFB mode can use an initialization vector. The IV is more important than in CBC mode, because if two data streams are encrypted with the same key, and have the same IV, then both streams can be recovered. In practice, avoid reusing the same key when using CFB mode. OFB (Output Feedback) mode is another way of turning a block cipher into a stream cipher. OFB mode works more like a traditional stream cipher than CFB mode, and is therefore more susceptible to the same kind of bit-flipping attacks that affect stream ciphers (generally not a problem if you use a message authentication code). A compelling feature of OFB mode is that most of the work can be done offline. That is, you can generate a keystream before there is even data available to encrypt, while you have spare CPU cycles. The plaintext simply gets XOR'd into the keystream. OpenSSL doesn't directly support keystream precomputation. OFB mode can also use an IV. As with CBC mode, avoid using the same key to encrypt multiple data streams, particularly if you always use the same IV.

5.1.3 EVP API

The OpenSSL API for symmetric cryptography is vast. Each cipher has its own set of routines for encryption and decryption. OpenSSL also provides a single API that serves as an interface to all symmetric encryption algorithms: the EVP interface, which can be accessed by including

37

openSSL/evp.h. The EVP API provides an interface to every cipher OpenSSL exports. Before using the EVP interface, we must know how to get a reference to the different ciphers we may wish to use. OpenSSL represents ciphers as data objects that generally get loaded behind the programmer's back. When you wish to use a particular cipher, you simply request a reference to the object associated with that cipher. There are two common methods for doing this. First, OpenSSL provides a method for each cipher in each mode of interest for that cipher, which loads the cipher data object into memory if necessary. For example, we can use the following code to get a reference to the Blowfish-CBC cipher object: EVP_CIPHER *c = EVP_bf_cbc();

EVP_Seal... and EVP_Open... provide public key encryption and decryption to implement digital ``envelopes''.

The EVP_Sign... and EVP_Verify... functions implement digital signatures.

Symmetric encryption is available with the EVP_Encrypt... functions. The EVP_Digest... functions provide message digests.

Algorithms are loaded with OpenSSL_add_all_algorithms.

All the symmetric algorithms (ciphers) and digests can be replaced by ENGINE modules providing alternative implementations. If ENGINE implementations of ciphers or digests are registered as defaults, then the various EVP functions will automatically use those implementations automatically in preference to built in software implementations.

5.1.4 Ciphers

5.1.4.1 AES

AES is the new Advanced Encryption Standard, which is also called Rijndael, it is available only in OpenSSL Versions 0.9.7 or later. AES is a block cipher that supports key and block sizes of 128, 192, and 256 bits. OpenSSL does not provide support for using AES in CFB or OFB modes. See Table 5.1.41.

Table 5.1.4.1 Referencing the AES cipher (OpenSSL 0.9.7 only) Cipher mode Key/block size EVP call for cipher object String for cipher lookup

ECB 128 bits EVP_aes_128_ecb() aes-128-ecb

CBC 128 bits EVP_aes_128_cbc() aes-128-cbc

38





AES has been designed with the state of art in the cryptographic research and is still believed very secure by most of the people. It has been designed to have very strong resistance against the classical approximation attacks, such as linear cryptanalysis, differential cryptanalysis etc. However, since AES is very algebraic, new algebraic attacks have appeared.

In a recent paper (Asiacrypt 2002), Nicolas Courtois and Josef Pieprzyk show that Rijndael can be written as an overdefined system of multivariate quadratic equations (MQ). For example authors show that for 128-bit Rijndael, the problem of recovering the secret key from one single plaintext can be written as a system of 8000 quadratic equations with 1600 binary unknowns. Thus the security of Rijndael requires that there are no efficient algorithms for solving such systems. In a paper published at Eurocrypt 2000 Shamir et al. describe an algorithm called XL (or/and FXL) able to solve efficiently many such systems of equations. Attacking AES/Rijndael by such a method requires only a few known plaintexts to succeed. If this method can be made to work in practice, it is a major revolution in cryptanalysis: all classical attacks on block ciphers such as linear/differential and other approximation attacks require a number of plaintexts that is very big and grows exponentially in the number of rounds.5

In practice the algorithm XL fails to break AES. However the system obtained from AES is not random, and has many special properties: it is overdefined, sparse and very structured. From this, in a recent paper, Nicolas Courtois and Josef Pieprzyk investigate how to improve XL and adapt it to such special systems. They propose a new class of attacks, attack, called XSL attacks. There is no doubt that attacks such as XL and XSL do work in many interesting cases. Unfortunately they are heuristic, and their behavior is not well understood. There are examples where these or similar attacks do behave in practice as it is predicted, and there are examples where they don't.

5.1.4.2 Blowfish

Blowfish is a block cipher designed by Bruce Schneier of Applied Cryptography. This algorithm has a good security margin and is the fastest block cipher OpenSSL provides. The key length of Blowfish is variable (up to 448 bits), but generally, 128-bit keys are used. The block-size for this cipher is fixed at 64-bits. Its biggest drawback is that key setup time is slow. As a result, Blowfish isn't a good choice when many different keys are used to encrypt short data items. Table 5.1.4.2 gives details.

39

Table 5.1.4.2 Referencing the Blowfish cipher Cipher mode EVP call for cipher object String for cipher lookup ECB EVP_bf_ecb() bf-ecb CBC EVP_bf_cbc() bf-cbc CFB EVP_bf_cfb() bf-cfb OFB EVP_bf_ofb() bf-ofb There is no effective publicly known cryptanalysis of blowfish , although the 64-bit block size is now considered too short, because encrypting more than 232 data blocks can begin to leak information about the plaintext due to a birthday attack. Despite this, Blowfish seems thus far to be secure. While the short block size does not pose any serious concerns for routine consumer applications like e-mail, Blowfish may not be suitable in situations where large plaintexts must be encrypted, as in data archival. In 1996, Serge Vaudenay found a known-plaintext attack requiring 28r + 1 known plaintexts to break, where r is the number of rounds. Moreover, he also found a class of weak keys that can be detected and broken by the same attack with only 24r + 1 known plaintexts. This attack cannot be used against the full 16-round Blowfish; Vaudenay used a reduced-round variant of Blowfish. Vincent Rijmen, in his Ph.D. thesis, introduced a second-order differential attack that can break four rounds and no more. There remains no known way to break the full 16 rounds, apart from a brute-force search. In 2005, Dieter Schmidt investigated the Blowfish key schedule and noted that the subkeys for the third and fourth round are independent of the first 64 bits of the user key6. Despite this fact it is impossible to attack the Blowfish because it affects only 2 out of 18 subkeys.

5.1.4.3 CAST5

The CAST5 algorithm, authored by Carlisle Adams and Stafford Tavares, is another cipher with variable-length keys and 64-bit blocks. The CAST5 specification allows for key lengths between 5 and 16 bytes (40 and 128 bits; keys must be a multiple of 8 bits in length). OpenSSL defaults to using 128-bit keys. CAST5 have a good resistance to differential cryptanalysis, linear cryptanalysis, and related-key cryptanalysis. This cipher also possesses a number of other desirable cryptographic properties, including avalanche, Strict Avalanche Criterion (SAC), Bit Independence Criterion (BIC), no complementation property, and an absence of weak and semi-weak keys. CAST is a fast cipher with no known weaknesses. See Table 5.1.4.3

40

Table 5.1.4.3 Referencing the CAST5 cipher Cipher mode EVP call for cipher object String for cipher lookup ECB EVP_cast_ecb() cast-ecb CBC EVP_cast_cbc() cast-cbc CFB EVP_cast_cfb() cast-cfb OFB EVP_cast_ofb() cast-ofb

5.1.4.4 DES

DES, the Data Encryption Standard, uses fixed 64-bit blocks and 64-bit keys. Eight bits are parity bits, giving a maximum of 56 bits of strength. These days, the parity bits are usually completely ignored. DES dates back to the mid-1970s and is certainly the most widely scrutinized symmetric algorithm available. While no significant attacks better than brute force have ever been found, brute force is a very real attack, since a 56-bit keyspace is widely considered too small. Additionally, DES is the slowest of the ciphers OpenSSL supports, except for more secure DES variants. It is a good idea to avoid vanilla DES unless you are supporting legacy systems. See Table 5.1.4.4

Table 5.1.4.4 Referencing standard DES Cipher mode EVP call for cipher object String for cipher lookup ECB EVP_des_ecb() des-ecb CBC EVP_des_cbc() des-cbc CFB EVP_des_cfb() des-cfb OFB EVP_des_ofb() des-ofb

5.1.4.5 Triple DES

Triple DES, often written as 3DES, is the most popular variant of DES and is probably the most conservative symmetric cipher available, due to the wide scrutiny DES has seen in the past quarter century. It is also the slowest algorithm available, though acceleration hardware can help. With 3DES, encryption is performed by encrypting data using DES, "decrypting" the ciphertext using a second key, then encrypting the data again, either with the original key (two-key 3DES) or with a third key (three-key 3DES). Three-key 3DES is always a better choice than two-key, as it is more secure and is no slower. The only drawback is that it requires a few extra bits for storing the additional key material. See Table 5.1.4.5. Table 5.1.4.5 Referencing 3DES Cipher mode EVP call for cipher object String for cipher lookup ECB (3 key) EVP_des_ede3() des-ede3 CBC (3 key) EVP_des_ede3_cbc() des-ede3-cbc

41

CFB (3 key) EVP_des_ede3_cfb() des-ede3-cfb OFB (3 key) EVP_des_ede3_ofb() des-ede3-ofb ECB (2 key) EVP_des_ede() des-ede CBC (2 key) EVP_des_ede_cbc() des-ede-cbc CFB (2 key) EVP_des_ede_cfb() des-ede-cfb OFB (2 key) EVP_des_ede_ofb() des-ede-ofb

5.1.4.6 IDEA

The IDEA cipher is a good all-around block cipher with 128-bit keys and 64-bit blocks. It is fast and is widely regarded as strong. Its major drawback is that it is covered by patent in the U.S. and Europe. Nonetheless, you can use the algorithm without paying a fee for noncommercial purposes. IDEA is about 10 years old and has seen a fair amount of scrutiny. Bruce Schneier highly recommends the algorithm in Applied Cryptography, and it is commonly used with PGP. Table 5.1.4.6 gives more information. Table 5.1.4.6 Referencing IDEA Cipher mode EVP call for cipher object String for cipher lookup ECB EVP_idea_ecb() idea-ecb CBC EVP_idea_cbc() idea-cbc CFB EVP_idea_cfb() idea-cfb OFB EVP_idea_ofb() idea-ofb RSA Security says that IDEA was analyzed to measure its strength against differential cryptanalysis. The analysis concluded that IDEA is immune to that technique. In fact, there are no linear cryptanalytic attacks on IDEA, and there are no known algebraic weaknesses in IDEA. The only weakness of note was discovered by Daemen7: using any of a class of 251 weak keys during encryption results in easy detection and recovery of the key. "However, since there are 2128 possible keys, this result has no impact on the practical security of the cipher for encryption provided the encryption keys are chosen at random. IDEA is generally considered to be a very secure cipher and both the cipher development and its theoretical basis have been openly and widely discussed.

5.1.4.7 RC2

The RC2 algorithm is a block cipher from RSA Labs. RC2 supports variable-length keys up to 128 bytes. OpenSSL's implementation uses a default length of 16 bytes (128 bits). There's an additional parameter for setting the "effective" key strength. What this means is you can take, say, a 128-bit key and cripple it to 40 bits worth of security. We strongly recommend against using this parameter. RC2 is efficient and has no significant published weaknesses. However, the algorithm has not really seen

42

a great deal of scrutiny, particularly compared to DES and AES. Table 5.1.4.7 gives the details.

Table 5.1.4.7 Referencing RC2 Cipher mode EVP call for cipher object String for cipher lookup ECB EVP_rc2_ecb() rc2-ecb CBC EVP_rc2_cbc() rc2-cbc CFB EVP_rc2_cfb() rc2-cfb OFB EVP_rc2_ofb() rc2-ofb

5.1.4.8 RC4

RC4 is a stream cipher with variable-length keys that can be up to 256 bytes long. RC4 was previously a trade secret but is now in common use due to the publication of a reverse-engineered, third-party implementation. RC4 is a stream cipher and is blazingly fast compared to the available block ciphers in OpenSSL. It's certainly the fastest algorithm currently implemented in OpenSSL. RC4 is also well-regarded as an algorithm. For this reason, and due to its widespread use in SSL, it's vastly popular, though it is widely used with insecure 40-bit keys. THE RC4 encryption algorithm itself is good, but some problems with the way it sets up keys require care in using it. In particular, RSA Security recommends you take one of the following two steps when using this algorithm: 1. Make sure that all key material is cryptographically hashed before use. The problem necessitating this solution is most prominent when frequently rekeying RC4. A common approach to frequent rekeying is to use a base key, and then concatenate with a counter. In RC4, that turns out to be a bad thing to do. If you take the key material and the counter and hash them together to get the actual key, the weakness goes away. The general recommendation of hashing all key material before use is a good one, no matter which cipher you use in your applications. 2. Discard the first 256 bytes of the generated key stream before using it. The easy way to do this is to encrypt 256 bytes of random data and discard the results. Additionally, as previously noted, it is particularly important to supplement use of RC4 with a MAC to ensure data integrity. See Table 5.1.4.8 for more information.

43

Table 5.1.4.8 Referencing RC4 Key length EVP call for cipher object String for cipher lookup 40 bits EVP_rc4_40() rc4-40 128 bits EVP_rc4() rc4

Jovan Dj. Golic in his paper Linear Statistical weakness of Alleged RC4 Keystream Generator has shown that the second binary derivative of the least significant bit output sequence is correlated to 1 with the correlation coefficient close to n3215 −⋅ where n is the variable word size of RC4. The output sequence length required for the linear statistical weakness detection may be realistic in high speed applications if 8≤n . The result can be used to distinguish RC4 from other keystream generators and to determine the unknown parameter n, as well as for the plaintext uncertainty reduction if n is small.8

Itsik Mantin and Adi Shamir In their paper “A pratical attack on broadcast RC4”describe a major statistical weakness in RC4 which makes it trivial to distinguish between short outputs of RC4 and random strings by analyzing their second bytes. This weakness can be used to mount a practical ciphertext-only attack on RC4 in some broadcast applications, in which the same plaintext is sent to multiple recipients under different keys.

5.1.4.9 RC5

RC5 is another block cipher from RSA Security. Its name is trademarked, and its algorithm is covered by an issued patent. RC5 is interesting because it is fast, well-regarded, and highly customizable. According to the RC5 specification, you can choose 64-bit or 128-bit blocks, use keys up to 255 bytes in size, and can use any number of cipher rounds, up to 255. However, OpenSSL's implementation uses 64-bit blocks and limits rounds to 8, 12, or 16, defaulting to 12. See Table 5.1.4.9. Table 5.1.4.9 Referencing RC5 Cipher mode Key bits Rounds EVP call for cipher object String for cipher

lookup

ECB 128 12 EVP_rc5_32_16_12_ecb() rc5-ecb

CBC 128 12 EVP_rc5_32_16_12_cbc() rc5-cbc

CFB 128 12 EVP_rc5_32_16_12_cfb() rc5-cfb

OFB 128 12 EVP_rc5_32_16_12_ofb() rc5-ofb

44

5.2. Public Key Cryptography and Key Agreement

5.2.1. Diffie-Hellman (DH)

These functions implement the Diffie-Hellman key agreement protocol. The generation of shared DH parameters is described in DH_generate_parameters; DH_generate_key describes how to perform a key agreement. The DH structure consists of several BIGNUM components. struct { BIGNUM *p; // prime number (shared) BIGNUM *g; // generator of Z_p (shared) BIGNUM *priv_key; // private DH value x BIGNUM *pub_key; // public DH value g^x // ... }; DH The Diffie-Hellman key agreement protocol (also called exponential key agreement) was developed by Diffie and Hellman in 1976 and published in the ground-breaking paper "New Directions in Cryptography." The protocol allows two users to exchange a secret key over an insecure medium without any prior secrets. The primary use of Diffie-Hellman is shared-secret negotiation. The algorithm itself can be made to provide for authentication, but OpenSSL doesn't include any high level interfaces for using these features, so they must be implemented by the application if they're desired. For this reason, most OpenSSL applications that use this algorithm will also use another for authentication. For our purposes, we will discuss Diffie-Hellman mainly from the perspective of key agreement. Diffie-Hellman guarantees a shared secret will be created that is suitable to use as the key to a symmetric algorithm. Failing to provide authentication through some other means, either with authenticated extensions to the implementation or through use of another algorithm such as DSA, leaves the protocol susceptible to man-in-the-middle attacks. In certain cases, Diffie-Hellman can be subject to a type of attack known as a small-subgroup attack. This attack results in a reduction of the computational complexity of brute-forcing the peer's private

45

key value. Essentially, a small-subgroup attack can result in the victim's private key being discovered. There are several different methods of protecting Diffie-Hellman against this type of attack. The simplest method is to use ephemeral keying. If both parties stick to ephemeral keying and use a separate method of authentication, small-subgroup attacks are thwarted. This isn't always feasible, however, mostly due to computational expense. If static keys will be used, two simple mathematical checks can be performed on the public key received from a peer to ensure these attacks aren't possible. If the key passes both tests, it's safe to use. The first test verifies that the supplied key is greater than 1 and less than the value of the p parameter. The second test computes yq mod p, in which y is the key to test and q is another large prime. If the result of this operation is 1, the key is safe; otherwise, it is not. The q parameter is not generated by OpenSSL even though there is a placeholder for it in the DH structure. An algorithm for generating q can be found in RFC 2631

5.2.2. Digital Signature Algorithm (DSA)

These functions implement the Digital Signature Algorithm (DSA). The generation of shared DSA parameters.

DSA is a public-key method based on the discrete logarithm problem.

The DSA structure consists of several BIGNUM components.

struct { BIGNUM *p; // prime number (public) BIGNUM *q; // 160-bit subprime, q | p-1 (public) BIGNUM *g; // generator of subgroup (public) BIGNUM *priv_key; // private key x BIGNUM *pub_key; // public key y = g^x // ... } DSA;

In public keys, priv_key is NULL.

No efficient attacks have yet been reported on this form of the discrete logarithm problem. Some researchers warned about the existence of "trapdoor" primes in DSA, which could enable a key to be easily broken. These trapdoor primes are relatively rare and easily avoided if proper key-generation procedures are followed.

46

The Digital Signature Algorithm mandated by the Federal Information Processing Standard FIPS 186. This is a public key system, but unlike RSA it can only be used for making signatures.

Digital Signature Algorithm is a public key algorithm that is used as part of the Digital Signature Standard (DSS). DSA was developed by the U.S. National Security Agency to generate a digital signature for the authentication of electronic documents. It cannot be used for encryption, only for digital signatures. The algorithm produces a pair of large numbers that enable the authentication of the signatory, and consequently, the integrity of the data attached. DSA is used both in generating and verifying digital signatures.

A digital signature is useful for verifying the integrity of data, ensuring that it has not been corrupted or tampered with. It also provides non-repudiation since only one person should have access to the private key used to compute a signature. The utility of a digital signature when combined with a key exchange algorithm such as Diffie-Hellman is easy to see. If the two parties performing a key exchange trust that the public key actually belongs to the party with which they're communicating, a digital signature can be used to prevent a man-in-the-middle attack.

5.2.3. RSA

These functions implement RSA public key encryption and signatures as defined in PKCS #1 v2.0 [RFC 2437].

The RSA structure consists of several BIGNUM components. It can contain public as well as private RSA keys:

struct { BIGNUM *n; // public modulus BIGNUM *e; // public exponent BIGNUM *d; // private exponent BIGNUM *p; // secret prime factor BIGNUM *q; // secret prime factor BIGNUM *dmp1; // d mod (p-1) BIGNUM *dmq1; // d mod (q-1) BIGNUM *iqmp; // q^-1 mod p // ... }; RSA

In public keys, the private exponent and the related secret values are NULL.

47

p, q, dmp1, dmq1 and iqmp may be NULL in private keys, but the RSA operations are much faster when these values are available.

Invented in 1977, RSA was the first public key algorithm capable of both digitally signing and encrypting data. Despite the fact that it was patented, it became the de facto public key algorithm. Almost any company that used public key cryptography in their products licensed the technology. It was patented only in the United States, and the patent expired on September 20, 2000. The algorithm's strength lies in the infeasibility of factoring extremely big numbers, and after 25 years of extensive cryptanalysis, it remains unbroken.

5.3 Certificates

5.3.1 x509

A X.509 certificate is a structured grouping of information about an individual, a device, or anything one can imagine. A X.509 CRL (certificate revocation list) is a tool to help determine if a certificate is still valid. The exact definition of those can be found in the X.509 document from ITU-T, or in RFC3280 from PKIX. In OpenSSL, the type X509 is used to express such a certificate, and the type X509_CRL is used to express a CRL.

Certificates are useful for authentication in Web applications, but note a few words of caution. Certificates don't encrypt data; rather, they identify someone or something. For example, when it uses SSL, the server certificate doesn't encrypt the SSL channel. Instead, the server certificate identifies the server to the client. When a user visits a site that uses SSL, the browser asks the server to identify itself by means of its certificate. The browser can check the CA and the dates on the certificate to make sure the certificate is valid and thus authorize SSL with the server. After the browser authenticates to the server, the browser and server agree on a key that's used to encrypt the channel.9 Another point to consider is maintenance. For an intranet, you must handle the acquisition and distribution of the certificates. You can automate this process by using Certificate Services to generate the certificates and link them to AD. You can also use native Win2K AD mapping to let AD manage the certificates. No matter which approach you use, however, you must deal with certificate creation or acquisition and updating those certificates when they expire or are revoked. In addition, certificates can cause security problems because users can let other people access their certificate. If someone has access to a certificate or a computer on which the certificate resides for the account the user is using, that person can access any site to which the certificate grants access.

48

People can also obtain a certificate under false pretenses. However, you must consider the management overhead associated with certificates as you determine whether they're right for your organization. Certificate revokation lists (CRL) are themselves an enormous issue for PKI. The idea is simple enough--each CA maintains a list of revoked certificates that can be checked every time an application wishes to use a certificate. But consider the implications of that statement. Certificates can no longer be used offline, but require access to the most current CRL. The CRL itself can be quite lengthy, so the mere process of downloading the CRL is nontrivial, both for the application and for any network that supports the CRL service. Note that even changing the CRL service means that all current certificates must be revoked, because the Certificate Revocation List Distribution Point gets included in those certificates. CRLs neither scale well, nor follow any real world paradigm. If you can imagine a global PKI where every use of a certificate involved downloading the current CRL, you can see one problem. Another is that the mechanism is one that has already been proven unworkable. Credit card companies used to publish lists of stolen or revoked credit cards, but they stopped doing this long ago in favor of online authorization. A similar mechanism does exist for PKI, in which instead of downloading a CRL, the application validating a certificate checks with the issuing CA to see if the certificate has been revoked. The Online Certificate Status Protocol, OCSP, attempts to deal with this problem, although even this protocol turns out to be too vague to be useful.10

5.4 Authentication Codes, Hash Functions

Cryptographic one-way hashes take arbitrary binary data as an input and produce a fixed-size binary string as an output, called the hash value or the message digest. Passing the same message through a single hash function always yields the same result. There are several important properties exhibited by cryptographic message digests. First, the digest value should contain no information that could be used to determine the original input. For that to be true, a one-bit change in the input data should change many bits in the digest value (on average, half). Second, it should be extremely difficult to construct a second message that yields the same resulting hash value. Third, it should also be difficult to find any two messages that yield the same hash value. The most conservative characterization of the security afforded by a given hash function is measured by how hard it is to find two arbitrary messages that yield the same hash value. Generally, the security of a well-respected hash function that has a digest size of n bits should be about as secure as a well-respected symmetric cipher with half as many bits. For example, SHA1, which has a 160-bit digest size, is about as resistant to attack as RC5 with 80-bit keys. Some uses of these algorithms

49

give security equal to their bit length that's just a good, conservative metric. People frequently use cryptographic hash functions that they believe provide security, but that don't really provide very much. For example, it is common to release software along with an MD5 digest of the software package (MD5 is a common cryptographic hash function). The intention is to use the digest as a checksum. The person downloading software should also obtain the MD5 digest, and then calculate the digest himself on the downloaded software. If the two digests match, it would indicate that the downloaded software is unaltered. Unfortunately, there are easy ways to attack this scheme. Suppose an attacker has maliciously modified a copy of the distribution of software package X, resulting in package Y. If the attacker can break onto the server and replace X with Y, then certainly, the checksum MD5(X) is also easily replaceable with the checksum MD5(Y). When a user validates the downloaded checksum, he will be none the wiser. Even without access to the actual server, attackers could replace X with Y and MD5(X) with MD5(Y) as they traverse the network. The fundamental problem is that nothing in this scenario is secret. A much better solution for this kind of scenario is a digital signature, which anyone can verify, but only someone with the correct private key can generate. Hash functions by themselves aren't often good for security purposes. The major exception is password storage. In such a situation, passwords are not stored, only hashes of passwords are stored, usually combined with a known "salt" value to avoid dictionary attacks in cases where the password database is stolen. When a user tries to log in, the hash of the entered password is compared against the one stored in the password database. If it's the correct password, the hashes will be identical. Even this scenario works only if a trusted data source collects the authentication information through a trusted data path. If a client computes the hash and sends it in the clear over a network, an attacker can capture the hash and replay the information later to log in. Worse, if the server computes the hash, but the client sent the password in the clear over a network, an attacker could capture the transmission of the password. One common use of hashes is as primitives in other cryptographic operations. For example, digital signature schemes generally work by hashing the input, then encrypting the hash with a private key. Doing so is generally far more efficient than performing public key encryption on a large input. Another frequent use is to remove any trace of patterns in data such as cryptographic keys. For example, you should hash your key material to make an RC4 key, instead of using the key material directly.

50

Another use of hashes is to ensure the message integrity of encrypted data, by encrypting the hash of a message along with the message itself. This is a primitive version of a message authentication code (MAC). A MAC generally uses a regular hash function as a primitive. The MAC algorithm produces a hash value from the data to protect a secret key. Only people with the correct secret key can forge the hash value, and only people with the secret key can authenticate the hash value. One good thing about MACs is that they can provide integrity, even in the absence of encryption. Another good thing is that the best MACs tend to have provable security properties under reasonable assumptions about the strength of the hash algorithm in use. The algorithm we just described as an example doesn't have either of these advantages. Like other cryptographic primitives, you should avoid creating your own MAC algorithm, even if it seems easy. There are good algorithms with provable properties, such as HMAC, which is currently the only MAC provided by OpenSSL. Why take the risk?

5.4.1. Hashing with the EVP API

Much like with symmetric cryptography, OpenSSL's cryptographic library has an API for each hash algorithm it provides, but the EVP API provides a single, simple interface to these algorithms. Just as with symmetric key encryption, there are three calls, one for initialization, one for "updating" (adding text to the context), and one for finalization, which yields the message digest. At initialization time, you must specify the algorithm you wish to use. Currently, OpenSSL provides six different digest algorithms: MDC2, MD2, MD4, MD5, SHA1, and RIPEMD-160. The first four have digest sizes that are only 128 bits. It is recommended to avoid them except to support legacy applications. In addition, there are known attacks on MD4, and it is widely considered to be a broken algorithm. SHA1 is more common than RIPEMD-160 and is faster, but the latter is believed to have a slightly better security margin. Recent developments on SHA-1: On February 2005, three Chinese cryptographers showed that SHA-1 is not collision-free. That is, they developed an algorithm for finding collisions faster than brute force. SHA-1 produces a 160-bit hash. That is, every message hashes down to a 160-bit number. Given that there are an infinite number of messages that hash to each possible value, there are an infinite number of possible collisions. But because the number of possible hashes is so large, the odds of finding one by chance is negligibly small (one in 280, to be exact). If you hashed 280 random messages, you'd find one pair that hashed to the same value. That's the "brute force" way of finding collisions, and it depends solely on the length of the hash value. "Breaking" the hash function means being able to find collisions faster than that. And that's what the Chinese cryptographers did. They can find collisions in SHA-1 in 269 calculations, about 2,000 times faster than brute force.11 For each digest, at least one function returns an instance of the algorithm. Look up algorithms by

51

name by calling OpenSSL_add_all_digests and EVP_get_digestbyname, and passing in an appropriate identifier. In both cases, a data structure of type EVP_MD represents the algorithm. Table 5.4.1 shows all of the message digest algorithms supported by OpenSSL, including the EVP call to get a reference to the algorithm, the digest name for lookup purposes, and the size of the resulting digests. Table 5.4.1 Message digests and the EVP interface Hash algorithm EVP call for getting EVP_MD String for lookup Digest length (in bits)

MD2 EVP_md2() md2 128



MDC2 EVP_mdc2() mdc2 128

SHA1 EVP_sha1()

EVP_dss1()

sha1

dss1

160

RIPEMD-160 EVP_ripemd160() ripemd 160

The MDC2 algorithm is a construction for turning a block cipher into a hash function. It is usually used only with DES, and OpenSSL hardcodes this binding. The SHA1 and DSS1 algorithms are essentially the same; the only difference is that in a digital signature, SHA1 is used with RSA keys and DSS1 is used with DSA keys.

52

6. Known Attacks on SSL

“You're making security decisions with substandard data. Word will eventually get out -- the Window of Exposure will grow -- but you have no control, or knowledge, of when or how. All you can do is hope that the bad guys don't find out before the good guys fix the problem.” -- Bruce Schneier

SSL protocol is intended to provide a practical, application-layer, widely applicable connection oriented mechanism for the clients and servers communications security. In fact, the SSL record layer provides confidentiality, authenticity, and replay protection over a connection-oriented reliable transport layer such as TCP. Generally, there are two kinds of attacks on the protocol namely, passive attacks and active attacks. A passive attack or eavesdropping including traffic analysis and chosen-plaintext, is one in which the attacker is only able to monitor the communications channel and it threatens confidentiality. An active attack including cut-and-paste and short block, is one in which the attacker attempts to add, delete, or modify messages and it threatens both confidentiality and data integrity. In addition to these attacks, there are a number of flaws in the protocol that cause much concerns. In particular, each layer in SSL uses services provided by a lower layer and also provides the functionality to higher layers. The SSL handshake protocol is located just above the record layer where it initializes and synchronizes cryptographic state at the two endpoints. Once the synchronization completes, sensitive application data can be sent via the SSL record layer. So, modifying the key exchange protocol allows the attackers to read the sensitive application data.

6.1 Passive attacks

Passive attacks can be further subdivided into ciphertext-only attacks, known-plaintext attacks, chosen-plaintext attacks, and chosen-ciphertext attacks. Ciphertext-only attacks attempt to deduce the plaintext from only the ciphertext but they have low chance of succeeding against strong encryption. An example of ciphertext-only attack is traffic analysis as explained in the following section. A known-plaintext attack is when the attacker has access to a collection of plaintext messages and their corresponding ciphertext. If same key is used to encrypt multiple blocks, frequency analysis is possible. Another kind of passive attack is chosen-plaintext attack which differs from chosen-ciphertext attack in the way the attackers choose the message. While in chosen-plaintext attack the attacker gets to choose a message to be encrypted so he could learn something about other ciphertexts, in chosen-ciphertext attack the attacker chooses ciphertext and sees the corresponding plaintext.

53

SSL protocol encrypts all application-layer data with a cipher and short-term session key negotiated by the handshake protocol and a wide choices of strong algorithms used in standard modes are available to handle passive attacks or eavesdropping such as traffic analysis and chosen-plaintext. The way the key management is handled by SSL provides the opportunities for the eavesdroppers to retrieve the known plaintexts. But, due to the strong encryption algorithm against known plaintext attacks, even though the eavesdroppers know the plaintext, it is difficult for them to launch attacks on these plaintexts. However, such passive attacks may cause much concerns if, for example, customers’ sensitive financial information such as credit card numbers are leaked to the attackers. In the following section, we describe traffic analysis, one kind of ciphertext-only attacks.

6.1.1 Traffic analysis

In the traffic analysis attack, the attackers recover confidential information about protection sessions by examining unencrypted packet fields and unprotected packet attributes. For example, by examining the unencrypted IP source and destination addresses (and even TCP ports), or examining the volume of network traffic flow, it can be determined what parties are interacting, what type of services are in use, and even sometimes recover confidential information. Except for those users in major corporations or organizations where confidential information is top secret, the majority of users typically consider the threat of this kind to be relatively harmless, so SSL does not attempt to stop this kind of traffic analysis. Even if it seems that the threats posed by traffic analysis are harmless, the author of paper[10] reveals that by examining the ciphertext lengths, URL requests in SSL-encrypted Web traffic can be retrieved. Here, when a web browser connects to a Web server via an encrypted transport such as SSL, the GET request containing the URL is transmitted in encrypted form. Thus, which Web page was downloaded by the browser is considered confidential information since traffic analysis can recover the identity of the Web server and the length of the html data returned by the Web server. This leak could allow an eavesdropper to discover what Web page was accessed. This vulnerability is present particularly in stream ciphers since the ciphertext length reveals the plaintext length. However, in block ciphers, plaintexts are padded out to the next 8-byte boundary, so attacker can only recover a close estimate of the plaintext length. In fact, SSL includes support for random padding for the block cipher modes, but not for the stream cipher modes.

6.1.2 Chosen-Plaintext

Although the underlying encryption algorithm should provide some of levels of security against adaptive chosen-plaintext/chosen-ciphertext attacks, it follows[12] that when utilizing block ciphers

54

for encryption, the SSL standard mandates the use of the cipher block chaining or CBC mode of encryption which requires an initialization vector (IV) in order to encrypt. Although the initial IV used by SSL is a pseudo random string which is generated and shared during the initial handshake phase, subsequent IVs used by SSL are chosen in a deterministic, predictable pattern. Since the IV of a message is taken to be the final ciphertext block of the immediately-preceding message, it allows vulnerability in SSL which enables easy recovery of low-entropy strings such as passwords or PINs that have been encrypted. The paper[12] argues that because of the open nature of Web browsers, a feasible point of entry is opened for an attack to enter. In this particular attack, an attacker may know in advance the IV that is going to be used to encrypt the next message. By making a validate guessing on the particular plaintext block, an attacker eventually can determine the value of a low-entropy string such as password or a PIN. Moreover, in a chosen-plaintext attack, attacker wants to verify a guess to whether a particular block has a particular value, for example, PINs. Moreover, after observing the ciphertext (C1, …, Cn), the attacker wants to determine whether plaintext block Pj is equal to some string P*. In this case, we assume that the attacker knows the IV that will be used when encrypting the next message. If the attacker causes the sender to encrypt P’ whose initial block P1’ is equal to Cj-1 XOR Cn XOR P*, the first ciphertext block C1’ is then computed as:

C1’ = Fsk (P1’ XOR Cn) = Fsk (Cj-1 XOR Cn P* XOR Cn) = Fsk (P* XOR Cj-1)

But, Cj = Fsk (Pj XOR Cj-1), it implies that C1’ = Cj if Pj = P*. Here, the attacker can verify a guess P* for the value of any plaintext block Pj. Similarly, if Pj is one of the N possible values, then by repeating the attack N/2 times, the attacker can determine the actual value of Pj. In practice, the plaintext block containing the user’s PIN usually contains other information such as headers, etc. Next, how can the attacker recover the user’s PIN? There are several requirements for chosen-plaintext attacks to be successful which include: (1) the attacker must know which plaintext block j contains the desired information, for example, he knows the format of the HTTPS transmission being targeted, (2) the attacker must know Cj-1 which is not difficult since the ciphertext travels over the Internet, (3) the attacker must know the value of the IV that is going to be used for the next message which can be obtained from the last ciphertext block of the previous message, and (4) the attacker must be able to insert a plaintext block of its choice into the first block of the next message to be transmitted which is the most challenging part for the attacker. By encouraging the user to use a plug-in of the attacker’s, the fourth requirement can be met.

55

In order to prevent chosen-plaintext attacks, a new random IV is used for each new message fragment to be encrypted. Also, the chosen-plaintext attack can be avoided by changing the CBC mode to counter mode[13] with a stateful counter.

6.2 Active attacks

Active attacks can be subdivided into different categories: known-key, replay, impersonation, dictionary, and forward search. In known-key attack, an attacker obtains previously-used keys and uses this to deduce information about new keys and thus he can track the generation of pseudorandom numbers. Another active attack is replay where an attacker records a communication session and replays part of it at a later time, for example login and key exchange. Next in the categories is impersonating where an attacker assumes the identity of one or more members of the network. Similarly, reflection attack occurs when the message is reflected back to the sender. In this case, an attacker intercepts, pretends to be the receiver and initiates the same protocol. Also, the attacker catches sender’s response and pretends this is receiver’s response to the original challenge. Further, dictionary attack is when an attacker uses a large list of words to deduce a password. For example: UNIX password attacks. And lastly, the forward search is actually a brute-force search of keyspace. In the following section, we describe variations of these active attacks namely cut-and-paste and short block attacks.

6.2.1 Cut-and-Paste

In paper[11], the author presents the cut-and-paste attack which exploits the principle that most endpoint applications will treat inbound encrypted data differently depending on the context where the applications will protect the data more when it appears in different forms. By taking advantage of a basic property of the cipher-block chaining (CBC) mode where the mode recovers from errors within one block, so inserting a few consecutive ciphertext blocks between locations within a ciphertext stream will result in a corresponding transfer of plaintext blocks, except for one block error at the beginning of the splice. Furthermore, the attacker cuts an encrypted ciphertext from some packet containing sensitive data, and splices it into the ciphertext of another packet which is carefully chosen so that the receiving endpoint will be likely to inadvertently leak its plaintext after decryption. When the attacks occur on the record layer of SSL, they could be used to compromise site security, for example, in the server to client Web page transfer, a ciphertext from a sensitive part of the html transfer is spliced into the hostname portion of a URL already included in the transferred Web page. So, after the user clicks on this fake URL link, his browser will interpret the decryption of the spliced sensitive ciphertext as a hostname and send a DNS domain name lookup for this hostname in the clear mode ready for an eavesdropper to capture it. By decrypting the sensitive ciphertext, the unsuspected

56

receiver leaks sensitive data to the eavesdropper. As shown in figure 6.2, Bob is allowed to impersonate Alice.

Bob can transform this

A -> B: CA , CB, { {Kab, Ta}Ka_1 }Kb

into this:

B -> C: CB, CC, {{Kab, Tc}Ka_1}Kb

and send the message to Carol

Fig. 6.2 Cut-and-Paste Attack Bob can read that segment (including the session key Kab) because it's encrypted with his public key. Carol does nothing to ensure that it's fresh. The simplest fix is to request Alice to sign the ciphertext of a message encrypted to Bob: A -> B: CA , CB, { {Kab, Ta}Kb }Ka

-1 Moreover, the cut-and-paste attack can be avoided by using independent session keys for each different context as SSL version 3.0 provided. SSL version 3.0 prevents cutting and pasting between different directions of a connection but it can not prevent cutting and pasting within one direction of a transfer. Another solution to prevent this kind of cutting and pasting attacks is for both servers and clients to use strong authentication on all encrypted packets to prevent modification of the ciphertext data.

6.2.2 Short-Block

Originally, the short block attack was applied against DES-CBC IPSEC-protected TCP data when the final message block contained a short one-byte plaintext and the remainder of it was filled by random padding. There are no obvious short-block attacks on standard SSL-encrypting Web servers since they do not typically encrypt short blocks. Similarly, a SSL-encrypting telnet should have robust protection against short-block attacks whenever each one-byte-long packet of keystroke is sent.

57

6.3 Attacks on key exchange protocol

Previously, we described the commonly found active and passive attacks. In this section, we describe attacks especially on SSL key exchange protocol. The SSL 3.0 handshake protocol message flow involves: (1) the client and server negotiating a common ciphersuite acceptable to both and exchanging random nonces, (2) the client sends an encrypted pre_master_secret, (3) the client and server derive master_secret from the pre_master_secret, and (4) the client and server verify their protocol by authenticating all messages with the master_secret. The general goal of the key exchange process is to create a pre_master_secret known to the communicating parties and not to attackers. The pre_master_secret will be used to generate the master_secret. The master_secret is required to generate the finished messages, encryption keys, and MAC secrets. By sending a correct finished message, parties prove that they know the correct pre_master_secret. But, the key exchange protocol is not protected by a signature so as described earlier, by modifying the key exchange protocol, an attacker can read the sensitive application data. In order to understand how such attacks are possible, let’s consider the three authentication modes of SSL.

SSL supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel should be secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. In this respect, completely anonymous sessions can be established using RSA or Diffie-Hellman for key exchange. With anonymous RSA, the client encrypts a pre_master_secret with the server's uncertified public key extracted from the server key exchange message. The result is sent in a client key exchange message. Since eavesdroppers do not know the server's private key, it will be infeasible for them to decode the pre_master_secret. With Diffie-Hellman, the server's public parameters are contained in the server key exchange message and the client's are sent in the client key exchange message. Eavesdroppers who do not know the private values should not be able to find the Diffie-Hellman result (i.e., the pre_master_secret). Thus, completely anonymous connections only provide protection against passive eavesdropping. Unless an independent tamper-proof channel is used to verify that the finished messages were not replaced by an attacker, server authentication is required in environments where active man-in-the-middle attacks are a concern.

Furthermore, anonymous servers cannot authenticate clients, since the client signature in the certificate verify message may require a server certificate to bind the signature to a particular server. If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority. Similarly, authenticated clients must supply an acceptable certificate to the server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked.

58

6.3.1 RSA key exchange and authentication

With RSA, key exchange and server authentication are combined. The public key may be either contained in the server's certificate or may be a temporary RSA key sent in a server key exchange message. When temporary RSA keys are used, they are signed by the server's RSA or DSS certificate. The signature includes the current ClientHello.random, so old signatures and temporary keys cannot be replayed. Servers may use a single temporary RSA key for multiple negotiation sessions. However, the temporary RSA key option is useful if servers need large certificates but must comply with government-imposed size limits on keys used for key exchange.

After verifying the server's certificate, the client encrypts a pre_master_secret with the server's public key. By successfully decoding the pre_master_secret and producing a correct finished message, the server demonstrates that it knows the private key corresponding to the server certificate.

When RSA is used for key exchange, clients are authenticated using the certificate verify message. The client signs a value derived from the master_secret and all preceding handshake messages. These handshake messages include the server certificate, which binds the signature to the server, and ServerHello.random, which binds the signature to the current handshake process.

6.3.2 Diffie-Hellman key exchange with authentication

When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or use the client key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSS or RSA certificate. Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters. In either case, the client can verify the certificate or signature to ensure that the parameters belong to the server.

If the client has a certificate containing fixed Diffie-Hellman parameters, its certificate contains the information required to complete the key exchange. Note that in this case the client and server will generate the same Diffie-Hellman result (i.e., pre_master_secret) every time they communicate. To prevent the pre_master_secret from staying in memory any longer than necessary, it should be converted into the master_secret as soon as possible. Client Diffie-Hellman parameters must be compatible with those supplied by the server for the key exchange to work.

If the client has a standard DSS or RSA certificate or is unauthenticated, it sends a set of temporary parameters to the server in the client key exchange message, then optionally uses a certificate verify message to authenticate itself.

59

6.3.3 Ciphersuite rollback

In the ciphersuite rollback attacks, the attackers silently force SSL version 2.0 clients and servers to use export-weakened encryption, even if both endpoints supported and preferred stronger grade algorithms. This can be done by editing the cleartext list of supported ciphersuites sent in the hello messages. In SSL version 3.0, however, all handshake protocol messages are authenticated with the master_secret such that at the end of the handshake and when session is terminated, the enemy tampering can be discovered. The way the key exchange protocol works can be explained as in the following:

• After completing the negotiation, client and server send short change cipher spec messages to each other to alert the other to upgrade the status of the pending session state to current.

• Immediately following the change cipher spec, the finished message which contains a MAC on all the handshake protocol messages keyed by the master_secret is sent.

Since the change cipher spec message is not protected by message authentication in the finished message, an attacker can intercept and delete the change cipher spec messages so that both the server and client never update their current ciphersuite and the following message authentication or encryption in the record layer for incoming packets are not secured. Furthermore, the rest of the interaction is not secure since the attacker strips the record layer authentication fields from the finished messages and session data. Without authentication protection, the attacker can modify the session data as he wishes as shown in figure 6.3a. However, with a strong encryption, the negotiated ciphersuite is encrypted and such attack can be foiled. By requiring the SSL implementation to receive a change cipher spec message before a finished message, such attack can be avoided as well.

Client Attacker Server Change cipher spec

Finished {a}k Finished a Change cipher spec Finished {a}k Finished a {m}k m Fig 6.3a Ciphersuite rollback attack.

60

Where {m}k is an authenticated message m with message authentication field keyed by k. Since no encryption is used, it is easy to recover m by stripping off the MAC field. The unprotected session data m can be replaced the attacker with his own.

6.3.4 Key-exchange algorithm rollback

Both client and server derive the KeyExchangeAlgorithm value from the negotiated ciphersuite. Since KeyExchangeAlgorithm is not protected by the signature, by modifying either client or server’s view of the negotiated ciphersuite which directly affects the KeyExchangeAlgorithm field, the attacker can abuse the server’s legitimitate signature on a set of Diffie-Hellman parameters. Thus, the attacker fools the client that the server signed a set of RSA parameters. A ciphersuite rollback attack forces the server to use the attacker’s Diffie-Hellman key exchange algorithm while the client uses RSA keying. Both client and server think that they have successfully negotiated their own ciphersuite. This attack can be summarized as in figure 6.3b.

Client Attacker Server (1) Server hello SSL_RSA…

SSL_DHE_RSA… (2) Server hello SSL_DHE_RSA… SSL_RSA… (3) Server key exchange {p, g, y}Ks {p, g, y}Ks (4) Client key exchange kg mod p gx mod p Fig 6.3b Key exchange algorithm rollback attack.

61

As shown in figure 6.3b, at the end of the key exchange, the client’s value of the pre_master_secret is k, while the server’s value is gxy mod p where x was chosen by the attacker.

6.3.5 Version Rollback

The ietf organization identifies version rollback attacks when the attackers may try to make SSL version 3.0 capable clients and servers fall back to SSL version 2.0. Due to the flexibility of SSL version 3.0 implementations, it may accept SSL version 2.0 connections. The attack can be done by forcing both endpoints to use SSL version 2.0 handshake protocols which is prone to security vulnerabilities. In this attack, the attacker modifies a SSL version 3.0 client hello to look like a SSL version 2.0 hello message and proceeds to exploit the vulnerabilities associated with SSL version 2.0 The solution to this attack is to embed some fixed redundancy in the RSA padding bytes e.g.: PKCS #1 block type 2 message padding, to indicate that the clients support SSL 3.0. Thus, servers which support SSL 3.0 will refuse to accept RSA encrypted key exchanges over SSL 2.0 compatibilities connections if the RSA encryption includes those distinctive non-random padding bytes. Therefore, it can provide a reasonably secure way for SSL 3.0 servers to detect the attack. However, this solution is not secure against attackers who can brute force the key and substitute a new ENCRYPTED-KEY-DATA message containing the same key (but with normal padding) before the application specified wait threshold has expired. Thus, parties concerned about such attacks should not be using 40-bit encryption keys anyway. Altering the padding of the least-significant 8 bytes of the PKCS padding does not impact security, since this is essentially equivalent to increasing the input block size by 8 bytes.

6.4 OpenSSL security vulnerabilities

While there have been continuous security vulnerabilities in openSSL, some of these problems have caused significant damages to clients and servers. The openSSL organization has provided continuous patches to handle such problems. For example, Denial of Service problems dated 17th March 2003 were caused by the null-pointer assignment in SSL handshake and the out-of-bounds read that affected Kerberos ciphersuites. These problems are usually fixed by upgrading the server software to newer versions. The more serious attacks on openSSL described by openSSL organization[14] from Dec 1998 to April 2005 as follows:

1. Klima-Pokorny-Rosa attacks on RSA in SSL/TLS (2003) Czech cryptologists[14] Vlastimil Klima, Ondrej Pokorny, and Tomas Rosa have come up with an extension of the "Bleichenbacher attack" on RSA with PKCS #1 v1.5 padding as

62

used in SSL 3.0 and TLS 1.0. Their attack requires the attacker to open millions of SSL/TLS connections to the server under attack; the server's behavior when faced with specially made-up RSA ciphertexts can reveal information that in effect allows the attacker to perform a single RSA private key operation on a ciphertext of its choice using the server's RSA key. Note that the server's RSA key is not compromised in this attack.

2. Timing-based attacks on RSA keys (2003)

Researchers[14] have discovered a timing attack on RSA keys, to which OpenSSL is generally vulnerable, unless RSA blinding has been turned on. Typically, it will not have been, because it is not easily possible to do so when using OpenSSL to provide SSL or TLS. The performance impact of blinding appears to be small (a few percent), however, this problem affects many applications using OpenSSL, in particular, almost all SSL-enabled Apaches.

3. Timing-based attacks on SSL/TLS with CBC encryption (2003) The attack[14] assumes that multiple SSL or TLS connections involve a common fixed plaintext block, such as a password. An active attacker can substitute specifically made-up ciphertext blocks for blocks sent by legitimate SSL/TLS parties and measure the time until a response arrives: SSL/TLS includes data authentication to ensure that such modified ciphertext blocks will be rejected by the peer (and the connection aborted), but the attacker may be able to use timing observations to distinguish between two different error cases, namely block cipher padding errors and MAC verification errors. This is sufficient for an adaptive attack that finally can obtain the complete plaintext block.

6.4.1 Denial of Service

Denial of Service or DoS attacks have become a major problem on the Internet[24]. Major web sites have been taken down for several hours at a time by distributed denial of-service (DDoS). The attackers have shown an interesting combination of skill and ignorance. They are able to break into tens or hundreds of machines and install their tool of choice. A “Denial of Service” attack prevents any legitimate users of the service from using that service[25]. Such attacks include but are not confined to, flooding the network and thereby preventing legitimate network traffic; disrupting services to a specific machine or set of machines. DoS attacks can also be launched by altering the configuration of a service or by consuming the resources of a service in extraordinarily large amounts, thereby depriving the other users of those resources.

63

The openSSL organization recently identified null-pointer assignment in SSL handshake and the out-of-bounds read that affected Kerberos ciphersuites as in the following announcement[17]:

1. Null-pointer assignment during SSL handshake Testing performed by the OpenSSL group using the Codenomicon TLS Test Tool uncovered a null-pointer assignment in the do_change_cipher_spec() function. A remote attacker could perform a carefully crafted SSL/TLS handshake against a server that used the OpenSSL library in such a way as to cause OpenSSL to crash. Depending on the application this could lead to a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0079 to this issue. All versions of OpenSSL from 0.9.6c to 0.9.6k inclusive and from 0.9.7a to 0.9.7c inclusive are affected by this issue. Any application that makes use of OpenSSL's SSL/TLS library may be affected.

2. Out-of-bounds read affects Kerberos ciphersuites

Stephen Henson discovered a flaw in SSL/TLS handshaking code when using Kerberos ciphersuites. A remote attacker could perform a carefully crafted SSL/TLS handshake against a server configured to use Kerberos ciphersuites in such a way as to cause OpenSSL to crash. Most applications have no ability to use Kerberos ciphersuites and will therefore be unaffected. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0112 to this issue. Versions 0.9.7a, 0.9.7b, and 0.9.7c of OpenSSL are affected by this issue. Any application that makes use of OpenSSL's SSL/TLS library may be affected.

6.4.2 Klima-Pokorny-Rosa attacks on RSA in SSL/TLS

In the paper[16], the authors presented a practically feasible attack on RSA-based sessions in SSL/TLS protocols. These protocols incorporate the PKCS#1 (v.1.5) encoding method for the RSA encryption of a pre_master_secret value. The pre_master_secret is the only secret value that is used for deriving all the particular session keys. Therefore, an attacker who can recover the pre_master_secret

64

can decrypt the whole captured SSL/TLS session. The authors proved that by incorporating a version number check over PKCS#1 plaintext used in the SSL/TLS, a side channel can be created that allows the attacker to invert the RSA encryption. The attacker can then either recover the pre_master_secret or sign a message on behalf of the server. The attack is an extension of Bleichenbacher’s attack on PKCS#1 (v. 1.5). In Bleichenbacher’s attack, the concrete encoding method called EME-PKCS1-v1_5, which is also employed in SSL/TLS protocols, is highly vulnerable to chosen plaintext attacks[17]. For more information on chosen-plaintext attacks, refer to section 6.2.2. Bleichenbacher’s attacks assume that information about the course of the decoding process is leaking to the attacker. These attacks are also called side channel attacks where the side information allows the attacker to break the particular realization of the RSA scheme. Also, the information can be used to decrypt any captured ciphertext or to sign any arbitrary message by using a common interaction with the attacked cryptographic module. By steering the attackers from knowing details about the course of the decoding process, such attacks can be avoided.

6.4.3 Timing attacks on RSA

Two out of three attacks on openSSL found by the organization since 1998 involve the timing attacks. Timing based attacks on RSA take advantages of how the system generates and stores RSA keys. Older RSA systems used the time of day to generate the public-private key pair, and if an attacker could narrow down the times when the system created the key then the number of prime numbers that would have to be checked while factoring would be severely diminished. Fortunately, newer RSA systems use much safer forms of key generation such as mouse movements. Other versions of timing attacks[18] have been found by researchers recently. They suggest that timing attacks are still feasible against many web servers. By measuring the amount of time a server takes to respond to queries, it is possible, even through multiple routers and switches, to extract private keys from a system. How it works

As in the case of timing attacks on RSA, by measuring the time required to perform decryption (exponentiation with the private key as exponent), an attacker can figure out the private key. Timing attacks of this version exploit the timing variations in cryptographic operations. Because of performance optimizations, computations performed by a cryptographic algorithm often take different amounts of time depending on the input and the value of the secret parameter. If RSA private key operations can be timed reasonably accurately, in some cases statistical analysis can be applied to recover the secret key involved in the computations.

There are several possible countermeasures to prevent the timing attacks:

65

- use constant exponentiation time - add random delays - blind values used in calculations

Moreover, researchers have recommended that the RSA blinding is turned on to protect the servers against timing attacks. With RSA blinding, randomness is introduced into the RSA computations to make timing information unusable. Before decrypting the ciphertext C, we first compute X = reC mod N, where r is a random value and e is the public exponent. We decrypt X as usual, i.e., compute Xd mod N = red Cd mod N = r Cd mod N again by Euler’s Theorem. We then multiply the output by r-1 to obtain Cd mod N which is the plaintext we want. Since a different r is used for each message, the original message is changed in a random way before the exponentiation operation. Thus, blinding prevents an attacker from entering a known input to the exponentiation function and using the resulting timing information to reveal the key.

6.4.4 Timing attacks on SSL/TLS with CBC encryption

Similarly, the timing attacks on SSL/TLS with CBC encryption[19] can be described in this section. The attacks against CBC mode ciphers as employed by TLS 1.0 have resulted in the use of a slightly modified version of CBC that requires explicit initialization vectors (IVs). The new version is likely to be a feature of TLS 1.1. How it works As shown in figure 6.4b, in explicit IV mode, a random data block is attached to record data. All encrypted block are transmitted, and the receiver simply discards the first plaintext block to retrieve record data.

Fig 6.4b CBC Encryption with Explicit IV

C1 C2 C3

E

R M2 M3

E E

IV

66

7. Conclusions

Security comes at a cost, as we have seen from our performance benchmarking results. OpenSSL provides a wide array of cryptographic algorithms for users and other applications to choose from. The choice of best combination might vary depending on the requirement and the objective you are trying to achieve. As OpenSSL implements different cryptographic algorithms it inherits all the security loopholes of these algorithms. In few known cases there are workarounds or fixes implemented by OpenSSL but mostly it is up to the users and applications utilizing OpenSSL crypto library to make the right choice by themselves.

Cryptographic algorithms that rely on modular exponentiation such as RSA and Diffie-Hellman may be vulnerable to timing attacks. If the exponentiation operation that involves the secret key can be timed by an attacker with reasonable accuracy, the key can be recovered by using carefully selected input values, the number of which being proportional to the length of the key. Researchers have implemented timing attacks against an earlier version of the CASCADE smart card[20], and three different OpenSSL-based RSA decryption applications. They showed that it is feasible to recover the RSA private keys used in these systems. Defenses against such attacks are possible. Today, the most widely used method is RSA blinding which incurs a small performance penalty of 2% to 10%. Timing attacks illustrate that attackers do not necessarily play by the presumed rules and they will always attack the weakest link in a system. Strong cryptography gives us security only if it is implemented and used in ways that complement its strength.

67

8. References

1 Transport Layer Security: How much does it really cost? (By: George Apostolopoulos, Vinod Peris, Debanjan Saha. IBM T.J. Watson Research Center, 1999) 2 How fast is the RSA algorithm? (http://www.rsasecurity.com/rsalabs/node.asp?id=2215) 3 OpenSSL Manual page documenting the OpenSSL Crypto library (http://www.openSSL.org/docs/crypto/crypto.html) 4 Network Security with OpenSSL (By Pravir Chandra, Matt Messier, John Viega O'Reilly, June 2002) 5 Algebraic Attacks on Combiners with Memory and Several Outputs? (By: Nicolas T. Courtois, October 18, 2004) 6 On the Key Schedule of Blowfish (By: Dieter Schmidt, 26 Feb 2005) http://eprint.iacr.org/2005/063 7 Weak keys for IDEA, Advances in Cryptology - Crypto '93 (By: J. Daemen, R. Govaerts, and J. Vandewalle, 1994) 8 Linear Statistical weakness of Alleged RC4 Keystream Generator (By: Jovan Dj. Golic, 1997) 9 Using Certificates for Security in IIS (By: Ken Spencer, September 2001) http://www.windowsitpro.com/Windows/Articles/ArticleID/21934/pg/1/1.html 10 PRIVATE KEY INFRASTRUCTURE Or, Why there is no Public Key Infrastructure (By: Rik Farrow) http://www.spirit.com/Network/net0903.html 11 Collision Search Attacks on SHA1 (By: Xiaoyun Wang, Yiqun Lisa Yin, Hongbo Yu, February 13, 2005) http://theory.csail.mit.edu/~yiqun/shanote.pdf 12 Teach yourself Apache 2 in 24 hours 2002 by Daniel Lopez Ridrujo 13. Yee B., Personal Communication, June 1996. 14. Bellovin S., “Problem areas for the IP security protocols”, Proc 6th USENIX Security Symposium, 1996, pp 205-214. 15. Bard G.V., “Vulnerability of SSL to Chosen-Plaintext Attack”, Department of Computer Science, University of Maryland, May 2004. 16. Bellare M., Desai A., Jokipii J., Rogaway P., “A Concrete Security Treatment of Symmetric Encryption: Analysis of the DES Modes of Operation”, Foundations of Computer Science, 1997. 17. http://www.openSSL.org/news 18. Brumley D. and Boneh D., “Remote timing attacks are practical”. 19. Vlastimil Klíma, Ondřej Pokorný, Tomáš Rosa, “Attacking RSA-based Sessions in SSL/TLS”,

Czech Technical University in Prague, 2003. 20. Bleichenbacher, D., “Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption

Standard PKCS#1, in Proc. of CRYPTO’98, pp 1-12, 1998. 21 Boneh D., Brumley D., Remote Timing Attacks are Practical”, Proceedings of the 12th USENIX

Security Symp., August 2003.

68

22 Modadugu N., Rescorla E., “The Design and Implementation of Datagram TLS”, Stanford

University 23. J.F. Dhem, F. Koeune, P.-A. Leroux, P. Mestré, J.-J. Quisquater, and J.-L. Willems, "A practical

implementation of the timing attack", at ww.cs.jhu.edu/~fabian/courses/CS600.264/Timing-full.pdf

24. Prashant Dewan, Partha Dasgupta, Vijay Karamcheti, “Defending against Denial of Service attacks using Secure Name Resolution” , Arizona State University 25. Dean D., Stubblefield A., “Using Client Puzzles to Protect TLS”, Rice University 26 SSL and TLS Essential Securing Web 2000 by Stephen Thomas

a practical study and analysis on openssl applicationcomp5351/main/openssl.pdf · a practical study...

Documents