Some solutions commonly used in order to guarantee a certain level of safety and security are:

1. SSL UNICAPT32 1.1 Introduction The following introduction contains large excerpts from the «TCP/IP Tutorial and Technical Overview IBM Redbook. Readers already familiar with SSL may directly go to section 1.1.3, which presents the SSL API in UNICAPT32. The SSL library will be delivered in several releases. Restrictions of release 1 are shown as follows: Release 1. Release 1 of SSL is compliant with LNET API documents 1.1 and 1.2. 1.1.1 Security Over the Internet Threats for terminals communicating over TCP/IP on a public network are numerous: tapping the wire, getting unauthorized access, getting access of information and changing it in transit, getting access to services that would normally be denied, getting access of encrypted data and passwords, and so on Some solutions commonly used in order to guarantee a certain level of safety and security are: - Encryption: to protect data and passwords, - Authentication by digital signatures and certificates: to verify who is sending data over the network, - Authorization: to prevent improper access, - Integrity checking: to protect against improper alterations of messages, - Frequent key refresh: to protect against the cracking of keys. The SSL library implements solutions to guarantee some of those security factors. 1.1.2 A Few Words On Cryptography The purpose of this chapter is to introduce the terminology and give a brief overview of the major cryptographic concepts that relate to TCP/IP security implementations. The information presented here only scratches the surface. Some issues are left open or not mentioned at all. SSL uses the concepts presented below: ciphers, symmetric and asymmetric algorithms, MAC, certificates and certificate authority. 1.1.2.1 Ciphers Encryption is the transformation of a clear text message into an unreadable form in order to hide its meaning. The opposite transformation, which retrieves the original clear text, is the decryption. The mathematical function used for encryption and decryption is the cryptographic algorithm or cipher. The currently used algorithms are keyed, that is, the encryption and decryption make use of a parameter, known as the key.

1.1.2.2 Symmetric Algorithms Symmetric algorithms are keyed algorithms where the decryption key is the same as the encryption key. These are conventional cryptographic algorithms where the sender and the receiver must agree on the key before any secured communication can take place between them. The private key is called the shared secret. Exemples are DES, 3-DES and RSA. DES operates on 64-bit blocks and has a key length of 56 bits. With 3-DES, the DES algorithm is applied in three rounds in order to improve security. The advantage of the symmetric algorithms is their efficiency. They can be easily implemented in hardware. A major disadvantage is the difficulty of key management. A secure way of exchanging the secret must exist. In SSL, symmetric algorithms are used for data exchange. 1.1.2.3 Asymmetric Algorithms Asymmetric algorithms address the major drawback of symmetric ciphers, i.e. the requirement of the secure key-exchange channel. The idea is that two different keys should be used: a public key which, as the name implies, is known to everyone, and a private key, which is to be kept in tight security by the owner. The private key cannot be determined from the public key. A clear text encrypted with the public key can only be decrypted with the corresponding private key. A clear text encrypted with the private key can only be decrypted with the corresponding public key. Thus, if someone sends a message encrypted with the recipient's public key, it can be read by the intended recipient only. An interesting property of the public-key algorithms is that they can provide authentication. The private key is used for encryption. Since anyone has access to the corresponding public key and can decrypt the message, this provides no privacy. However, it authenticates the message. If one can successfully decrypt it with the claimed sender's public key, then the message has been encrypted with the corresponding private key, which is known by the real sender only. Thus, the sender's identity is verified. Encryption with the private key is used in digital signatures. Examples of asymmetric algorithms are RSA and DH. Asymmetric algorithms, while providing for easier key management, privacy and authentication also have some disadvantages. The most important one is that they are slow and difficult to implement in hardware. Their most important use is key exchange and authentication. This is the way they are used in SSL. 1.1.2.4 MAC Message Authentication Codes (or MAC) are hashes (powerful checksums) that are encrypted with a key. They are used to assure integrity (if the MAC is correct, then the message is most probably unchanged). MACs may also be used to authenticate the issuer of a document by encrypting the MAC with a private key. In that case, the MAC is called a digital signature. Examples of hash functions are MD5 and SHA-1. SSL uses MACs to ensure message integrity.

1.1.2.5 Certificates and Certification Authorities (CA) One major security exposure in using public key algorithms is not knowing if the public key used really is the public key of the receiver. An intruder could replace a public key with its own and read encrypted messages that were supposed to go to the receiver. The origin of public keys needs to be certified. This is the role of certificates. A certificate is a file that binds an identity (the subject) to a public key. This binding is validated by a Certification Authority (the issuer). A digital certificate is signed with the private key of the certification authority, so it can be authenticated. It is only issued by the CA after a verification of the applicant. Apart from the public key and identification, a digital certificate usually contains other information, as shown below: Certificate Version Serial Number Issuer Name Validity Not before Not after Subject Name Subject Public Key Subject Public key algorithm Signature Algorithm Signature Certificate Version of the certificate (indicates if optional fields are being used) Identification number of the certificate assigned by the CA Name of the CA that issued the certificate Certificate not valid before this date Certificate not valid after this date Name of the entity identified by that certificate Public key of the entity identified by that certificate Algorithm associated to the public key Signature algorithm used by the CA to sign the certificate Signature of the whole certificate (signed by the CA) There is an international standard in place for digital certificates: The ISO X509 protocols described in RFC 3280. If needed, the parties retrieve each other's digital certificate and authenticate it using the public key of the issuing certification authority. They have confidence that the public keys are real, because a trusted third party vouches for them. When a terminal receives a server s certificate, it can only be trusted if the certificate was signed by a CA that the terminal trusts. A trusted CA called the ROOT is locally stored and all other CAs are trusted provided their certificates can belong to a chain made from the ROOT, where the next certificate s issuer in the chain is the current certificate s subject. This is shown in the diagram below.

ROOT certificate issuer = ROOT subject = CA1 validity certificate 1 issuer = CA1 subject = CA2 validity certificate 2 issuer = CA2 subject = CA3 validity.../... trusted certificates locally stored in the terminal SERVER'S CERTIFICATE TO VALIDATE issuer = CAn-1 subject = CAn validity If such a path can be established with the server's certificate at the end and all validity ranges correct, the server's certificate can be trusted. SSL uses certificates during the connection phase in order to certify the origin of public keys. 1.1.3 Secured Socket Layer (SSL) SSL is a security protocol that was developed by Netscape Communications Corporations, along with RSA Data Security, Inc. The primary goal of the SSL protocol is to provide a private channel between communicating applications, which ensures privacy of data, authentication of the partners, and integrity. SSL provides an alternative to the standard TCP/IP socket API that has security implemented within it. The SSL protocol addresses the following security issues: - Privacy: After the symmetric key is agreed upon in the initial handshake, the messages are encrypted using this key. - Integrity: Messages contain a message authentication code (MAC) ensuring the message integrity. - Authentication: During the handshake, the client authenticates the server using an asymmetric (a.k.a public) key. It can also be based on certificates. SSL is composed of two layers: - On the upper layer, a protocol for initial authentication and transfer of encryption keys, called the SSL Handshake Protocol. - At the lower layer, a protocol for transferring data using a variety of predefined ciphers and authentication combinations, called the SSL Record Protocol.

SSL works on top of TCP and offers a specific socket API to applications (the secured socket API): APPLICATIONS SSL API SSL handshake protocol record protocol TCP IP NETWORK INTERFACE NETWORK INTERFACE NETWORK INTERFACE In SSL terminology, the client is the peer that initiates the SSL connection. The handshake protocol is in charge of reaching an agreement between the client and the server. Both sides may identify each other and must agree on the cipher methods to be used. Once an SSL session has been established, the secured channel is transparent, that is, data is encrypted between the client and the server, but data sent at one end is exactly the same as data received at the other end. In Unicapt32, terminals are SSL clients, that is, they request SSL connections to SSL servers. Furthermore, terminals may request an identification of the server and provide a certificate to the server if this one want to identify the terminal. The following sequence diagram shows how a connection request from the terminal side translates into messages on the network.

Message Exchange in SSL v3 and TLSv1 (no client certificate) CLIENT (TERMINAL) SERVER clienthello (ssl version, client random, previous session id, supported ciphers) client checks server certificates client generates premaster secret client computes 48-byte master secret from premaster, server random and client random client computes CLIENT_WRITE_KEY serverhello (ssl version, server random, this session id, chosen cipher) serverx509certificatelist (server public key) serverkeyexchange (additional params)* serverhellodone clientkeyexchange {premaster secret} server public key clientchangecipherspecs {clientfinished} client_write_key server chooses a cipher suite and notifies of its choice if cipher is not anonymous, server sends its certificates for certain key exchange algorithm, server sends additional parameters separately* server computes 48-byte master secret from premaster, server random and client random server computes SERVER_WRITE_KEY serverchangecipherspecs {serverfinished} server_write_key {DATA} client-write-key {DATA} server-write-key encrypted with server's public key encrypted with agreed encryption method {...} xxx indicates a message encrypted with key xxx * the serverkeyexchange is sent only for the follow ing key exchange methods RSA_EXPORT w ith server key > 512 bits, DHE_DSS, DHE_DSS_EXPORT, DHE_RSA, DHE_RSA_EXPORT, DH_anon Step 1: the client sends a connection request with a clienthello message, which includes, among others, a list of supported cipher suites. Each cipher suite specifies authentication modes, key exchange modes, encryption and MAC algorithms. Step 2: the server evaluates the parameters sent by the clienthello and returns a serverhello message that includes, among others, the selected cipher suite and a session ID.

Step 3: If the server is requested to authenticate (that depends on the chosen cipher), it sends a serverx509certificatelist message, which contains its certificate(s) along with its public key(s), which authenticate its identity. Step 3 : in some cases, the server sends a serverkeyexchange message, which contains additional parameters related to the chose cipher. Step 4: the server sends a serverhellodone message and begins to wait for the client s response. Step 5: If the server has sent a certificate (step 3), the client checks the certificate. Then, it computes a pre-master secret and sends it in a clientcertificateverify message. This message is encrypted with the server s public key and can thus be decrypted only by the server. Step 6: the client generates the master secret that will be used for data encryption and sends a clientchangecipherspecs. Step 7: the client sends a clientfinished message indicating its negotiation part is finished. This is the first message encrypted with the symmetric algorithm chosen for the session. Step 8: the server generates the master secret that will be used for data encryption and sends a clientchangecipherspecs. Step 9: the server sends a serverfinished message indicating its negotiation part is finished. Step 10 Following the handshake, both session partners have generated a master key. From that key they generate other session keys (private keys), which are used in the symmetric-key encryption of the session data and in the creation of message digests (MACs). Note that the record protocol transmits frames in chunks of 16 kbytes at most. Message boundaries are not preserved (multiple messages may be coalesced into a single record, or a single message may be fragmented across several records). The first message encrypted with the agreed-upon symmetric cipher is the finished message from the client. If the server can interpret the finished message, it means: Privacy has been achieved, because the message is encrypted using a symmetrickey block- or stream-cipher (such as DES or RC4). The message integrity is assured, because it contains a Message Authentication Code (MAC), which is a message digest of the message itself plus material derived from the master key. The server has been authenticated, because it was able to derive the master key from the pre-master key. As this was sent using the server's public key, it could only have been decrypted by the server (using its private key). Note that this relies on the integrity of the server's public key certificate. The following diagram is a synthesis of the message sequence showing certificate and key exchanges in a specific case where Diffie-Hellman is used to exchange keys, authority used RSA to sign the certificate, data encryption is done with DES and MAC function is SHA1:

SSL SERVER HELLO HELLO check certificate certificate server name server public key signed by CA w ith RSA key pre master secret DH-encrypted with server's public key compute master secret and private keys compute master secret and private keys DATA EXCHANGE encrypted with private clear text encrypted w ith server's public key: Diffie-Hellman encryption w ith DES secret and MAC is SHA1 Simplified sequenced diagram for a DHE_RSA_WITH_DES_CBC_SHA cipher suite The Unicapt32 SSL library is compatible with SSLv2, SSLv3 (Netscape standards), and TLSv1 (latest IETF standard based on SSLv3 and described in RFC 2246). As compared with the RFC2246, the LSSL library does NOT support the optional feature of session caching, which allows a client to send a previous session ID in its client hello message in order to avoid cipher re-negotiation. 1.2 Supported Ciphers During the handshake, in the clienthello message, the terminal sends the cipher suites that it supports. Each cipher suite is composed of a list of algorithms, one for key exchange, one for certificate signing, one for encryption and one for MAC. The server (v3, tls) or the client (v2) will then select one of those. A cipher name is composed of the following elements: - the key exchange algorithm: algorithm used during key exchange, - the authentication method: key used in server certificate signature,

- the encoding method: algorithm for encoding data, - the MAC method, - an export flag: indicating export version of a cipher that may be distributed outside of the US, - a strength value: the number of bits of the symmetric key for encryption. This is a logical level instead of a fixed number (512 bits, 1024 bits ) so as to adapt to standard changes without having to change application code (currently, US law forbids exportation of more than 56-bit symmetric keys, and more than 1024-bit asymmetric keys). - and the SSL version. The table below lists all the ciphers that will be supported in the final release of LSSL: Cipher Name from RFC 2246 RFC Id (2 or 3 bytes in hexa) Key Exchan ge Algo Authenti cation method Ciphe r Algo RC4_128_WITH_MD5 01 00 80 RSA RSA RCA 128 MAC metho d Expor t Strengt h MD5 No Medium (128 RC4_128_EXPORT40_WITH_MD5 02 00 80 RSA RSA RCA 128 MD5 Yes EXP40 (40 RC2_CBC_128_CBC_WITH_MD5 03 00 80 RSA RSA RC2 MD5 No Medium (128 RC2_CBC_128_CBC_EXPORT40_WITH_MD5 04 00 80 RSA RSA RC2 MD5 Yes EXP40 (40 IDEA_128_CBC_WITH_MD5 05 00 80 RSA RSA IDEA MD5 No Medium (128 DES_64_CBC_WITH_MD5 06 00 40 RSA RSA DES MD5 No Low (56 DES_192_EDE3_CBC_WITH_MD5 07 00 C0 RSA RSA 3DES MD5 No High (168 RC4_64_WITH_MD5 (*) 08 00 80 RSA RSA RCA MD5 No Low V2 (64 RSA_WITH_NULL_MD5 00 01 RSA RSA NULL MD5 Yes None RSA_WITH_NULL_SHA 00 02 RSA RSA NULL SHA1 Yes None DH_anon_EXPORT_WITH_RC4_40_MD5 00 17 EDH NULL RC4 MD5 Yes EXP40 (40 DH_anon_WITH_RC4_128_MD5 00 18 EDH NULL RC4 MD5 No Medium (128 DH_anon_EXPORT_WITH_DES40_CBC_SHA 00 19 EDH NULL DES SHA1 Yes EXP40 (40 DH_anon_WITH_DES_CBC_SHA 00 1A EDH NULL DES SHA1 No Low (56 DH_anon_WITH_3DES_EDE_CBC_SHA 00 1B EDH NULL 3DES SHA1 No High (168 RSA_EXPORT_WITH_RC4_40_MD5 00 03 RSA RSA RC4 MD5 Yes EXP40 (40 RSA_WITH_RC4_128_MD5 00 04 RSA RSA RC4 MD5 No Medium (128 RSA_WITH_RC4_128_SHA 00 05 RSA RSA RC4 SHA1 No Medium (128 RSA_EXPORT_WITH_RC2_CBC_40_MD5 00 06 RSA RSA RC2 MD5 Yes EXP40 (40 RSA_WITH_IDEA_CBC_SHA 00 07 RSA RSA IDEA SHA1 No Medium (128 SSL versio n V2 V2 V2 V2 V2 V2 V2

RSA_EXPORT_WITH_DES40_CBC_SHA 00 08 RSA RSA DES SHA1 Yes EXP40 (40 RSA_WITH_DES_CBC_SHA 00 09 RSA RSA DES SHA1 No Low (56 RSA_WITH_3DES_EDE_CBC_SHA 00 0A RSA RSA 3DES SHA1 No High (168 DH_DSS_EXPORT_WITH_DES40_CBC_SHA 00 0B DHd DH DES SHA1 Yes EXP40 (40 DH_DSS_WITH_DES_CBC_SHA 00 0C DHd DH DES SHA1 No Low (56 DH_DSS_WITH_3DES_EDE_CBC_SHA 00 0D DHd DH 3DES SHA1 No High (468 DH_RSA_EXPORT_WITH_DES40_CBC_SHA 00 0E DHr DH DES SHA1 Yes EXP40 (40 DH_RSA_WITH_DES_CBC_SHA 00 0F DHr DH DES SHA1 No Low (56 DH_RSA_WITH_3DES_EDE_CBC_SHA 00 10 DHr DH 3ES SHA1 No High (168 DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 00 11 EDH DSS DES SHA1 Yes EXP40 (40 DHE_DSS_WITH_DES_CBC_SHA 00 12 EDH DSS DES SHA1 No Low (56 DHE_DSS_WITH_3DES_EDE_CBC_SHA 00 13 EDH DSS 3ES SHA1 No High (168 DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 00 14 EDH RSA DES SHA1 Yes EXP40 (40 DHE_RSA_WITH_DES_CBC_SHA 00 15 EDH RSA DES SHA1 No Low (56 DHE_RSA_WITH_3DES_EDE_CBC_SHA 00 16 EDH RSA 3DES SHA1 No High (168 FZA_DMS_NULL_SHA (*) 00 1C FZA FZA NULL SHA1 No None FZA_DMS_FZA_SHA (*) 00 1D FZA FZA FZA SHA1 No None FZA_DMS_RC4_SHA (*) 00 1E FZA FZA RC4 SHA1 No Medium (128 (*) not explicitly listed in RFC but supported by LSSL. Acronyms are explained in the glossary in appendix. EXPn indicates a cipher where n bits of the session key are sent in the clear and other bits encrypted. Export : indicates export version of a cipher that may be distributed outside of the US. Export versions have a secret key length restricted to 40 bits. Release 1 of LSSL supports 4 ciphers only: RC4_64_WITH_MD5, RSA_WITH_RC4_128_MD5, DHE_RSA_WITH_3DES_EDE_CBC_SHA and RSA_WITH_DES_CBC_SHA. In LSSL, a sub list of supported ciphers is linked to an object called a CONTEXT. Within that context, all sessions will send their sub-lists in their clienthello messages for the server to choose (v3,tls). Via sslcontextsetcipherlist(), the application passes the list of algorithms it wants to be used within a context and the SSL library computes the list of authorized ciphers. Example: The application indicates that the following algorithms may be used: RSA for key exchange, RSA for authentication, any algorithm for encryption and MAC, only non exportable algorithms and in any SSL version. From that information, the SSL library will send the following supported suites in the client Hello message: RC4_128_WITH_MD5, RC2_CBC_128_CBC_WITH_MD5, IDEA_128_CBC_WITH_MD5, DES_64_CBC_WITH_MD5, DES_192_EDE3_CBC_WITH_MD5,

RC4_64_WITH_MD5, RSA_WITH_RC4_128_MD5, RSA_WITH_RC4_128_SHA, RSA_WITH_IDEA_CBC_SHA, RSA_WITH_DES_CBC_SHA, RSA_WITH_3DES_EDE_CBC_SHA. 1.3 Example of an X509 certificate in PEM format: -----BEGIN CERTIFICATE----- MIIDNjCCAp+gAwIBAgIBITANBgkqhkiG9w0BAQQFADBdMQswCQYDVQQGEwJGUjEM MAoGA1UECBMDSURGMRAwDgYDVQQHEwdwdXRlYXV4MREwDwYDVQQKEwhpbmdlbmlj bzemmaoga1uecxqdcizkmq0wcwydvqqdewrnt01pmb4xdtazmtiwotezndy1nfox DTA0MTIwODEzNDY1NFowXzELMAkGA1UEBhMCRlIxEDAOBgNVBAgTB1B1dGVhdXgx DDAKBgNVBAcTA0lERjERMA8GA1UEChMIaW5nZW5pY28xDDAKBgNVBAsUA3ImZDEP MA0GA1UEAxMGc2VydmVyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3fksg GIes4gvtrc9BaaP0rVcf0MQ9oH2IKioGLPypD18Vna5i4VkDU3mj4og3s0Mc4q/3 KlHANNz/WCMbGj+Z5lNbyttL+qYnEBOv4r28JzADSfQQ1N0O5OGTmjNtidH+71dH /Rt1H+j/n8J9GdQJZRNFKDoDjeMMCGE+cWgzJQIDAQABo4IBAjCB/zAJBgNVHRME AjAAMBEGCWCGSAGG+EIBAQQEAwIGQDAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBH ZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLc0SvpfAcPUdvp3HJ/UXyc9 UzRfMG8GA1UdIwRoMGahYaRfMF0xCzAJBgNVBAYTAkZSMQwwCgYDVQQIEwNJREYx EDAOBgNVBAcTB3B1dGVhdXgxETAPBgNVBAoTCGluZ2VuaWNvMQwwCgYDVQQLFANy JmQxDTALBgNVBAMTBE1PTU+CAQAwIQYDVR0RBBowGIEWc2VydmVyQGZyLmluZ2Vu awnvlmnvbtanbgkqhkig9w0baqqfaaobgqa3epmvay+4wknq3dvq7g3xt3ea5eva LTGvTN2T59SgLmp34kRB4AB8jWDS65pMknNh/Hav8gKXlROa1bORKqTBtu/d+4vl 6qPiL7r2ny+ffwCp6V0uCsTqXyIWpU9/XXJVXuz2LOwedhbakeX4XeAyaERBEsWD siuq9p4fnwzteq== -----END CERTIFICATE----- 1.4 Example of an X509 certificate followed by a RSA private key in PEM format: -----BEGIN CERTIFICATE----- MIID8jCCA1ugAwIBAgIBAjANBgkqhkiG9w0BAQQFADCBnzELMAkGA1UEBhMCRlIx FjAUBgNVBAgTDUlsZS1kZS1GcmFuY2UxEDAOBgNVBAcTB1B1dGVhdXgxETAPBgNV BAoTCEluZ2VuaWNvMRIwEAYDVQQLEwlBdXRob3JpdHkxFjAUBgNVBAMTDURhdmlk IEdpcmF1bHQxJzAlBgkqhkiG9w0BCQEWGGRnaXJhdWx0QGZyLmluZ2VuaWNvLmNv btaefw0wntaxmjaxnda3mdhafw0wnjaxmjaxnda3mdhamhcxczajbgnvbaytakzs MRYwFAYDVQQIEw1JbGUtZGUtRnJhbmNlMRAwDgYDVQQHEwdQdXRlYXV4MREwDwYD VQQKEwhJbmdlbmljbzEOMAwGA1UECxMFVGVzdHMxGzAZBgNVBAMTEkNlcnRpZmll ZCBUZXJtaW5hbDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA6dMh1azTHRgs 8G2kWqiRqvYqY+u6O/IB4GS0drOX3X1Hvj9YMLE8BgDrAsRgHW3Bg/wpl7zZuWKv u9xfp1/pskvvmkd0ms/zazjiuegf8fypnw0towxqyefemv8l4y2y7cpx11ceifj3 QyE0hm5X9gQKnC8tj8yH2/zWJFyGpY0CAwEAAaOCAWMwggFfMAkGA1UdEwQCMAAw EQYJYIZIAYb4QgEBBAQDAgZAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVy YXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQULcTrf7WcezWFQDakapvKidVaJxkw gcwga1udiwsbxdcbwyaucfzuuatfnvkh6ejzv8zvbwtpqpohgawkgaiwgz8xczaj BgNVBAYTAkZSMRYwFAYDVQQIEw1JbGUtZGUtRnJhbmNlMRAwDgYDVQQHEwdQdXRl YXV4MREwDwYDVQQKEwhJbmdlbmljbzESMBAGA1UECxMJQXV0aG9yaXR5MRYwFAYD VQQDEw1EYXZpZCBHaXJhdWx0MScwJQYJKoZIhvcNAQkBFhhkZ2lyYXVsdEBmci5p bmdlbmljby5jb22caqawiwydvr0rbbwwgoeyzgdpcmf1bhrazniuaw5nzw5py28u Y29tMA0GCSqGSIb3DQEBBAUAA4GBAK3wB5rjhC8FRxQFjD1V98Q2CALZQe62LP4V 1k9sOMK7I9SsU/Pdx1MJpDPysEFujJyAKR29eC4i+nzolsJxvfFrtVfKcND6d8wk hhen6a+22bpzwyfx/ee4+u1l9zshnjqnb5+yu+av/mlzrl6+y/xd4nvukhvlrcqq mmetzuws -----END CERTIFICATE----- -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,BA9A46592E8B71AF 6vOshxzWR3sAxUckiSFDoUxkfA09u/JdrMnrkm9VLIyevT9BKZN7e7nL8oTqkiKr HJfH3fHF4hBOPNYoAgHizeimUhyhFVJBYPUiWJ3m8BxSN3CX6iatYlRAFzEwb+ba 6CUXzmKwC+eAXv8IUqeAr8eSsAkXHatyO0Hf/Qxf6f3lBXcJyNN+0gZTAGTJRlvE KI+vpwWiN/hWN048Cyj6INQeD53p1q3XBWLq25YHLydlAVKUW+5IXKjNsP0EhRZq s8bppvrjgribdehcdqkmkdgiofyz7nzve+ib7xwcbo4oyu5i6p31kbmprdsnuic7 ClVfM+N0ZfPqHKKrYD7Fw7nImLsM3ifl0XGWTfGojh57DtH4EwACKJuSoTXdRmlT /DO91DxpdBn1NdgxFaCHG2phlKB02k3gOUU7jO1WTrklM/K6kVrEyupbhZnYVwuX l9nyfdapczluundwt+qqk69n8xqgsngu/dynuwxin4bnqtrjyeyqknrs0ojqeyvi mg1w1tsxbs1t+4vez0jc5sbexwbsuhiowfnjcimo1muce9tyopeqmp9q1/vr+/js

8VR7SsJVVFg6dfRjPB76xsNnu+tXgqonI5jFvMgEOCnNEpTIXu8Ybnd6UYcuYCAJ KlBYscy6InS5M9AW3rmzFW2ueohQgN0v6KySQN+pqIN4oAswL4NgH8rEZY4zcuyp Q42GLXSZ8XkPP+wAubrvSgZFDzqExKK/u/CvCzhMDw3EHilpJ33P9d95ZFMFk+q0 wj5daz6tksnlnslg8ko5doiuaglgqjhd9flc/cggnd/jcjqrcdaasg== -----END RSA PRIVATE KEY----- 1.5 Appendix: List of X509 Error Codes The following table lists the errors that may occur during the verification of a server s certificate. Each error condition may lead to a termination or continuation of the handshake, as specified with function sslctxcertificateverifyset(). SSL_V_X509_OK SSL_V_X509_ERR_UNABLE_TO_GET _ISSUER_CERT SSL_V_X509_ERR_UNABLE_TO_DECRYPT _CERT_SIGNATURE SSL_V_X509_ERR_UNABLE_TO_DECODE _ISSUER_PUBLIC_KEY SSL_V_X509_ERR_CERT_SIGNATURE _FAILURE SSL_V_X509_ERR_CERT_NOT_YET_VALID SSL_V_X509_ERR_CERT_HAS_EXPIRED SSL_V_X509_ERR_ERROR_IN_CERT_NOT _BEFORE_FIELD SSL_V_X509_ERR_ERROR_IN_CERT_NOT _AFTER_FIELD SSL_V_X509_ERR_OUT_OF_MEM SSL_V_X509_ERR_DEPTH_ZERO_SELF _SIGNED_CERT SSL_V_X509_ERR_SELF_SIGNED_CERT _IN_CHAIN SSL_V_X509_ERR_UNABLE_TO_GET _ISSUER_CERT_LOCALLY SSL_V_X509_ERR_UNABLE_TO_VERIFY _LEAF_SIGNATURE SSL_V_X509_ERR_INVALID_CA SSL_V_X509_ERR_INVALID_PURPOSE SSL_V_X509_ERR_CERT_UNTRUSTED SSL_V_X509_ERR_CERT_REJECTED SSL_V_X509_ERR_SUBJECT_ISSUER _MISMATCH SSL_V_X509_ERR_AKID_SKID_MISMATCH SSL_V_X509_ERR_AKID_ISSUER_SERIAL _MISMATCH The operation was successful. The issuer certificate could not be found: this occurs if the issuer certificate of an untrusted certificate cannot be found. The certificate signature could not be decrypted. This means that the actual signature value could not be determined rather than it not matching the expected value, this is only meaningful for RSA keys. The public key in the certificate SubjectPublicKeyInfo could not be read. The signature of the certificate is invalid. The certificate is not yet valid: the notbefore date is after the current time. The certificate has expired: the notafter date is before the current time. The certificate notbefore field contains an invalid time. The certificate notafter field contains an invalid time. An error occurred trying to allocate memory. The passed certificate is self signed and the same certificate cannot be found in the list of trusted certificates. The certificate chain could be built up using the untrusted certificates but the root could not be found locally. The issuer certificate of a locally looked up certificate could not be found. This normally means the list of trusted certificates is not complete. No signatures could be verified because the chain contains only one certificate and it is not self signed. A CA certificate is invalid. Either it is not a CA or its extensions are not consistent with the supplied purpose. The supplied certificate cannot be used for the specified purpose. The root CA is not marked as trusted for the specified purpose. The root CA is marked to reject the specified purpose. The current candidate issuer certificate was rejected because its subject name did not match the issuer name of the current certificate. The current candidate issuer certificate was rejected because its subject key identifier was present and did not match the authority key identifier current certificate The current candidate issuer certificate was rejected because its issuer name and serial number was present and did not match

SSL_V_X509_ERR_KEYUSAGE_NO _CERTSIGN the authority key identifier of the current certificate. The current candidate issuer certificate was rejected because its keyusage extension does not permit certificate signing.

1.6 Message Exchange in SSL v2 Note that in SSL v2, the client chooses the cipher to be used, not the server. Message Exchange in SSL v2 (no session Id re-use and no client certificate) CLIENT (TERMINAL) SERVER clienthello (supported ciphers, challenge) serverhello (sublist of supported ciphers, certificate with server public key, connnection id) client chooses a cipher, determines a master key clientmasterkey {cipher chosen, master key} server-public-key client computes its CLIENT_READ_KEY(s) and CLIENT_WRITE_KEY(s) from master key, challenge and connection ID server computes its SERVER_READ_KEY(s) and SERVER_WRITE_KEY(s) serververify{challenge} server-write-key client decrypts challenge and checks clientfinished{sessionid} client-write-key serverfinished{sessionid} server-write-key {DATA} client-write-key {DATA} server-write-key encrypted with server's public key encrypted with symmetric algorithm {...} xxx indicates a message encrypted with key xxx

1.7 SSL Glossary Authentication Authentication is the ability of one entity to determine the identity of another entity. In SSL, authentication means the binding between a public key and a name and the the implicit ownership of the corresponding private key. Asymmetric cipher See public key cryptography. CA Certificate Cipher Client Certificate Authority that delivers certificates that can be trusted. As part of the X.509 protocol (a.k.a. ISO Authentication framework), certificates are assigned by a trusted Certificate Authority and provide a strong binding between a party's identity or some other attributes and its public key. Mathematical function used for encryption and decryption. The application entity that initiates a TLS connection to a server. This may or may not imply that the client initiated the underlying transport connection. The primary operational difference between the server and client is that the server is generally authenticated, while the client is only optionally authenticated. CLIENT_READ_KEY The session key that the client uses to initialize the client read cipher. This key has the same value as the SERVER-WRITE-KEY (symmetric algorithm). CLIENT_WRITE_KEY The session key that the client uses to initialize the client write cipher. This key has the same value as the SERVER-READ-KEY (symmetric algorithm). Digital signatures Encryption Handshake Digital signatures utilize public key cryptography and one-way hash functions to produce a signature of the data that can be authenticated, and is difficult to forge or repudiate. Transformation of a clear text message into an unreadable form in order to hide its meaning. An initial negotiation between client and server that establishes the parameters of their transactions.

Message Authentication Code (MAC) A Message Authentication Code is a one-way hash computed from a message and some secret data. It is difficult to forge without knowing the secret data. Its purpose is to detect if the message has been altered. Master secret Secure secret data used for generating encryption keys, MAC secrets, and IVs. Public key cryptography A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key can be verified with the public key. One-way hash function A one-way transformation that converts an arbitrary amount of data into a fixed-length hash. It is computationally hard to reverse the transformation or to find collisions. MD5 and SHA are examples of oneway hash functions. Session identifier A session identifier is a random value generated by a client that identifies itself to a particular server. The session identifier can be thought of as a handle that both parties use to access a recorded secret key (in our case a session key). If both parties remember the session identifier then the implication is that the secret key is already known and need not be negotiated. SERVER_READ_KEY See CLIENT_READ_KEY SERVER_WRITE_KEY See CLIENT_WRITE_KEY Symmetric cipher RSA DH Keyed algorithms where the decryption key is the same as the encryption key. Ron Rivest, Adi Shamir and Leonard Adleman algorithm. A very widely used public-key algorithm that can be used for either encryption or digital signing. The security of RSA relies on the difficult problem of factoring large numbers. As computing power grows, keeping RSA secure is a matter of increasing the key length (unlike DES, where the key length is fixed). Another public-key algorithm, actually the very first ever invented, is Diffie-Hellman. This is a key-exchange algorithm; that is, it is used for securely establishing a shared secret over an insecure channel. The communicating parties exchange public information from which they derive a key. An eavesdropper cannot reconstruct the key from the information that went through the insecure channel. More precisely, the reconstruction is computationally infeasible. The security of Diffie- Hellman relies on the difficulty of calculating discrete logarithms in finite

fields. After the shared secret has been established, it can then be used to derive keys for use with symmetric key algorithms such as DES. MD2 MD5 SHA1 RC4 RC2 an older version of MD5. MD5 is a hash algorithm designed by Ron Rivest. It produces a 128-bit hash. Used in keyed-mode, the key and data are concatenated as input to the algorithm so as to produce a MAC. SHA1 is a hash algorithm largely inspired from MD5. It was designed by the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA). It produces a 160-bit hash and is regarded as more secure than MD5. Used in keyed-mode, the key and data are concatenated as input to the algorithm so as to produce a MAC. a stream symmetric encryption algorithm licensed by RSA Data Security. a block symmetric encryption algorithm developed by Ron Rivest at RSA Data Security. IDEA symmetric algorithm: International Data Encryption Algorithm. It uses 64- bit blocks and 128-bit keys. It was aimed to replace DES. DES 3DES EDH DHd DHr DSS awell-known symmetric block algorithm, developed by IBM. It operates on 64-bit blocks and has a key length of 56 bits. From the key, 16 subkeys are derived, which are used in the 16 rounds of the algorithm. The DES algorithm applied three times to improve security. Ephemeral Diffie-Hellman xxx Acronym used in cipher suite definition indicating a suite using DH key agreement and DH certificates signed by CAs using DSS keys. Acronym used in cipher suite definition indicating a suite using DH key agreement and DH certificates signed by CAs using RSA keys. Digital Signature Standard. Digital authentication standard of the U.S. government. The standard describes a Digital Signature Algorithm used to sign and verify signatures of message digests produced with SHA1. X509 A format and management of certificates as described in RFC 3280. PEM Privacy Enhanced Mail. A former format and management of certificates described in RFC 1422 now deprecated by the X509 standard, which extends the PEM.