Certification Authorities CAs X 509 Certificates AUTHENTICATION Henrique

Certification Authorities (CAs) & X. 509 Certificates “AUTHENTICATION” Henrique Wallenstein how@student. dei. uc. pt

Certification Authorities & X. 509 Certificates Agenda: ü HISTORY; ü WHAT THEY ARE; ü WHY DO WE NEED THEM; ü HOW DOES IT LOOKS; ü HOW TO: ü Create a CA; ü Generate a Certificate Request; ü Sign and Return the Requested Certificate; ü WHERE ARE THEY USED; ü ATTACKS ü CRL & OCSP ü CONCLUSIONS & FUTURE ü BIBLIOGRAPHY

Certification Authorities & X. 509 Certificates History: X. 509 began in association with the X. 500 standard in 1988 (Version 1) and it assumed a hierarchical system of certification authorities for issuing of certificates. ü In 1993, an enhanced version of X. 509 - version 2 - was introduced with the addition of two more fields, support and directory access control. ü The X. 509 version 3, added compatibility with other topologies such as meshes and bridges, and the option to use it in a peer-to-peer, Open. PGP-similar web of trust environment (even though it is actually scarcely used that way). ü These days, the name X. 509 broadly refers to the IETF's PKI Certificate and CRL Profile of the X. 509 version 3 certificate standards, as given in the RFC 3280 specifications. ü

Certification Authorities & X. 509 Certificates What’s a X. 509 Certificate: A digital certificate is an asymmetric cryptography key. Current standards regarding digital certificates have identifying information included along with the key. ü A typical digital certificate contains the owner's name (or the full domain name, if it’s used on a Web Server) and contact information. ü There is a valid date range as well and a security signature to verify that the certificate has not been tampered with. ü

Certification Authorities & X. 509 Certificates Why do We Need Certification Authorities: A digital certificate created by just anyone is going to have a problem on the basis of trust. A digital certificate is more than just a cryptography key; it is an online credential. ü A certificate verifies your identity to whoever is attempting to communicate with you. To show trust, a digital certificate is signed by a Certificate Authority (CA). ü ü CAs act as a trusted third party in the world of digital security. Being an hierarchical method, there are several levels of CA’s, where “Trusted Introducers” (as a company) can ask for their own CA certificate and with that, sign their company’s members. ü

Certification Authorities & X. 509 Certificates Why do We Need Certification Authorities: Because verifying identity in the online world is difficult, CAs take over that challenge and verify the identity of anyone purchasing a certificate or paying to have their certificate signed. ü Thus to trust the certificate, the user only needs to trust the certificate authority. The user signifies trust in the certificate authority by possessing and using the CA's trust certificate. ü Verisign (www. verisign. com) and Thawte (www. thawte. com) are two well-known certificate authorities. ü Root certificates are implicitly trusted, and the best example of it are the software programs that already comes with preinstalled root certificates (CAs pays for it). ü

Certification Authorities & X. 509 Certificates How Does A Certificate Looks Like: A X. 509 certificate has three main variables the certificate, the certificate signature algorithm and the certificate signature. ü It’s described by attributes such as version, algorithm ID, serial number, issuer, subject, validity, subject public key info, extensions and several other optional ones like subject and issuer unique identifier. ü The subject public key info attribute is further detailed by the public key algorithm and subject public key, while validity attribute comes has further options for an upper and lower date limit, which eventually decides the life of the certificate. ü

Certification Authorities & X. 509 Certificates How to Create a CA Certificate: ü Create a Private Key: openssl genrsa -des 3 -out ca. key 4096 Generate a CA certificate: openssl req -new -x 509 -days 3650 -key ca. key -out ca. crt ü

Certification Authorities & X. 509 Certificates How to Create a SERVER / User Certificate Request: ü Create a Private Key: openssl genrsa -des 3 -out server. key 4096 Generate a CA Certificate Request: openssl req -new -key server. key –out server. csr ü The Common Name (CN) of the CA and the Server certificates should not match or else a naming collision will occur and that can be a problem later, giving some future errors. In this step, we are providing the CA entries. Now we have to provide the Server entries. In this example, I just added "CA" to the CA's CN field, to distinguish it from the Server's CN field. Use whatever schema you want, just make sure the CA and Server entries are not identical

Certification Authorities & X. 509 Certificates How to Request a Signed Certificate to CA: ü Sign and receive Certificate: an CA’s Server/User openssl x 509 -req -days 365 -in server. csr -CA ca. crt -CAkey ca. key -set_serial 01 -out server. crt To provide the Server entries to the CA, it takes a signing request (csr) and - with a given timestamp - makes a valid signed server certificate (crt) out of it. In doing so, it is necessary to tell which Certificate Authority (CA) to use, which CA key to use, and which Server key to sign. Also a serial number is required for further CRL identification. To confirm all this generated files, there’s the following commands: openssl rsa -noout -text -in ca. key openssl x 509 -noout -text -in ca. crt openssl rsa -noout -text -in server. key openssl req -noout -text -in server. csr

Certification Authorities & X. 509 Certificates Where Are They Used: IPSec – IPsec protocols operate at the network layer. This makes IPsec more flexible, as it can be used for protecting higher level protocols, including both TCP and UDP. S/MIME – S/MIME provides some cryptographic security services for electronic messaging applications like authentication, message integrity and non-repudiation of origin and data security (using encryption). The whole (prepared) MIME entity to be enveloped is encrypted and packed into an object which subsequently is inserted into an application/pkcs 7 -mime MIME entity. Smart. Cards – Most advanced smart cards are equipped with specialized cryptographic hardware that let you use algorithms such as RSA and DSA on board. Today's cryptographic smart cards are also able to generate key pairs on board, to avoid the risk of having more than one copy of the key (since by design there usually isn't a way to extract private keys from a smart card). Such Smart. Cards are mainly used for digital signature and secure identification. SSH – Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user and also let him access the command line of its account.

Certification Authorities & X. 509 Certificates Where Are They Used: HTTPS – https is a URI scheme used to indicate a secure HTTP connection. Using an https: URL indicates that HTTP is to be used, but with a different default TCP port (443) and an additional encryption/authentication layer between the HTTP and TCP. POP 3 S, IMAPS – The Internet Message Access Protocol is an application layer Internet protocol operating on port 993 that allows a local client to receive(POP 3) / access (IMAP) e-mail from a remote server, with the authentication process through SSL/TLS channel. LDAP(v 3) – The Lightweight Directory Access Protocol is an application protocol for querying and modifying directory services running over TCP/IP. Due to its basic design (among other factors) LDAP is often used by other services for authentication. EAP – EAP is a universal authentication framework frequently used in wireless networks and Point-to-Point connections. EAP provides some common functions and a negotiation of the desired authentication mechanism. Such mechanisms are called EAP methods and there are currently about 40 different methods like EAP-MD 5, EAP-OTP, EAP-GTC, EAP-TLS or EAPIKEv 2. Modern EAP methods can provide a secure authentication mechanism and negotiate a secure PMK (Pair-wise Master Key) between the client and NAS. The PMK can then be used for the wireless encryption session which uses TKIP or CCMP encryption.

Certification Authorities & X. 509 Certificates Attacks: ü For the next two slides, the refered attacks are more common in secure channels, where the cryphtoanalist has access to the encryption machine or the symetric key – witch is sended to the receiver encrypted with assymetric keys (Receiver’s X. 509 Certificate [Public Key]). ü The “real” attack in X. 509 private key (most common). ü Certificates is when an user loose their From na attacker, we can wait attacks like decrypting the public key to obtain the private key, or the creation of an Do. S attack so that the user cannot receive the CA’s certificate revoked list (explained later).

Certification Authorities & X. 509 Certificates Attacks (Having Access to the “decrypt machine / Key”): CHOSEN PLAINTEXT ATTACK: A chosen plaintext attack is an attack where the cryptanalyst is able to define his own plaintext, feed it into the cipher, and analyze the resulting ciphertext. Mounting a chosen plaintext attack requires the cryptanalyst to be able to send data of his choice into the device which is doing the encryption, and it requires the cryptanalyst to be able to view the output from the device. Because of these requirements, a chosen plaintext attack is in some cases impossible to attempt. A good example is the attacks on the German Enigma machine -the Allies could not mount a chosen plaintext attack on the Enigma until they were able to capture one! ü (KNOWN) PLAINTEXT ATTACK: A known plaintext attack is an attack where the cryptanalyst has access to the ciphertext and the plaintext of one or more pieces of data. A known plaintext attack is somewhat easier to mount than a chosen plaintext attack, because the first does not require the cryptanalyst to be able to feed data into the encryption device, it only requires him to know what data is being fed into the device. ü

Certification Authorities & X. 509 Certificates Attacks (Sniffing the Secure Channels): ü (KNOWN) CIPHERTEXT ATTACK: A known ciphertext attack is an an attack where the cryptanalyst only has access to encrypted ciphertext. It is the easiest of the common cryptanalysis attacks to mount, because is requires the least amount of control over the encryption device. Conversely, the known ciphertext is the most difficult of the common methods of cryptanalysis to execute successfully, because so little knowledge is known to begin with. ü BRUTE FORCE ATTACK: The difficulty of a brute force attack depends on several factors, such as: - How long can the key be? - How many possible values can each component of the key have? - How long will it take to attempt each key? DICTIONARY ATTACK (Applied to Symmetric keys); A dictionary attack consists of trying "every word in the dictionary" as a possible password for an encrypted message. A dictionary attack is generally more efficient than a brute force attack, because users typically choose poor passwords. Dictionary attacks are generally far less successful against systems that use passphrases instead of passwords. ü

Certification Authorities & X. 509 Certificates CRL Are Needed: A certificate revocation list (CRL) is a list of certificates (more accurately: their serial numbers) which have been revoked and should not be relied on by any system user. ü ü There are different revocation reasons (defined in RFC 3280) : - Revoked: A certificate is irreversibly revoked if, for instance, it is discovered that the certificate authority (CA) had improperly issued a certificate. Certificates may also be revoked for failure of the identified entity to adhere to policy requirements such as: - Publication of false documents, mis-representation of software behavior; - Violation of any other policy specified by the CA operator or its customer. The most common reason for revocation is the user's not being in sole possession of the private key (e. g token containing the private key has been lost or stolen). - Hold: This reversible status can be used to notice the temporary invalidity of the certificate, for instance when the user is not sure if the private key has been lost. If, in this example, the private key was found again and nobody had access to it, the status can be reinstated, and the certificate is valid again, thus removing the certificate from further CRLs.

Certification Authorities & X. 509 Certificates CRL Are Needed: The CRL is always issued by the CA which issues the corresponding certificates. All CRLs have a (often short) lifetime in which they are valid and in which they may be consulted by a PKI-enabled application to verify a counterpart's certificate prior its use. ü To prevent spoofing or Do. S attacks, CRLs are usually signed by the issuing CA and therefore carry a digital signature. To validate a specific CRL prior relying on it, the certificate of its corresponding CA is needed, which usually can be found on a (even public) directory. ü Certificate expiration dates are not a substitute for a CRL as the problem may be discovered whilst the certificate has not yet expired. CRLs or other certificate validation techniques are a necessary part of any properly operated PKI as mistakes in certificate vetting and key management are expected to occur in real world operations. ü

Certification Authorities & X. 509 Certificates CRL Are Needed, However…: Best practices require that wherever and however certificate status is maintained, it must be checked whenever one wants to rely on a certificate. Failing this, a revoked certificate may be incorrectly accepted as valid. This means that to use a PKI effectively one must have access to current CRLs (i. e. Internet access in the case of a PKI). ü The existence of a CRL implies the need for someone (or some organization) to enforce policy and revoke certificates deemed counter to operational policy. If a certificate is revoked mistakenly, significant problems can arise. ü The necessity of consulting a CRL, or other certificate status service, prior to accepting a certificate, raises a potential Do. S attack against the PKI whereby a current authentication token cannot be retrieved. ü No comprehensive solution to these problems is known, though there are multiple workarounds for various aspects of it, some of which have proven acceptable in practice: ü - An alternative to using CRLs which is especially useful for software clients, is the on-line certificate validation protocol “Online Certificate Status Protocol” (OCSP), witch has the primary benefit of requiring less network bandwidth and thus enabling real-time and near real-time status checks for high volume or high value operations.

Certification Authorities & X. 509 Certificates Online Certificate Status Protocol (OCSP): The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X. 509 digital certificate (RFC 2560). ü It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN. 1 and are usually communicated over HTTP. ü The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders. ü When deploying a PKI, certificate validation using OCSP may be preferred over the use of CRLs for several reasons, such as: - OCSP can provide more timely information regarding the revocation status of a certificate; - OCSP removes the need for clients to retrieve the (sometimes very large) CRLs themselves, leading to less network traffic and better bandwidth management; - Using OCSP, clients do not need to parse CRLs themselves, saving client-side complexity. - CRLs may be seen as analogous to a credit card company's "bad customer list" -- an unnecessarily public exposure. ü

Certification Authorities & X. 509 Certificates Conclusions & Future: ü X. 509 Certificates & CAs are EXTREMELY NEEDED in nowadays World (Servers, Companies, People, whatever); ü Software developers should prepare their software (electronic mail, web browsers, etc) to accept both CRL and OCSP algorithms and, later, only OSCP; ü New Encryption Methods are Necessary (Quantic Chypher);

Certification Authorities & X. 509 Certificates Bibliography: ü http: //www. tech-faq. com/x. 509. shtml ü http: //en. wikipedia. org/wiki/X. 509 ü http: //en. wikipedia. org/wiki/Certificate_revocation_list ü http: //en. wikipedia. org/wiki/Online_Certificate_Status_Protocol

Certification Authorities (CAs) & X. 509 Certificates QUESTIONS ? Henrique Wallenstein how@student. dei. uc. pt