COMP043-Cryptology Week 4 – Certs and Sigs

Digital Signatures Digital signatures provide –Integrity –Authenticity and –Non-repudiation How do they work? –You can make a signature using a public key cipher and a hash function –Some signature schemes use a special Signature Algorithm that is like a public key hash algorithm –Although we don't call them that

Digital Signatures Original document MD5 checksum ad cf 9c 83 7e 1c a7 a4 95 be c9 9f 84 7f 32 hex characters x 4 = 128 bits

Digital Signatures Notice that encryption uses private key

Digital Signatures

Digital Signatures - Checking Your system does this And checks against this

Integrity, Authenticity and Non-repudiation Integrity –Digest matches so message has not been tampered with Authenticity –Digest was encrypted with sender's private key, so digest wasn't tampered with –Message must be authentic message from key owner Non-repudiation –No one else has your private key

Signature Schemes, RSA RSA refers to a public key cypher Also refers to a digital signature scheme using the cipher Stronger if used to sign a hash, not the message –Related messages produce related signatures –Signing a hash removes relationship between related messages

ElGamal Signature Produces two signature components using complex math Verification combines the two Stronger than RSA

DSS, DSA Digital Signature Standard –Adopted by NIST in 1993 as FIPS 186 –Updated 1996, now FIPS DSA is the Digital Signature Algorithm used by DSS Based on ElGamal scheme Uses a pre-generated key plus a one time random number r Creates two sigs, one based only on r, one based on message digest and r Two are combined for verification Faster than RSA, smaller sigs than ElGamal

ECDSA Elliptic Curve DSA Based on different math Achieves same crypto strength as DSA using much smaller keys –So faster generation of same strength signature

Public Key Authenticity When we use a public key how do we know it is the right key? Someone (Eve) creates a phony key with the name and user ID of someone else (Alice) Bob uses this key to encrypt message for Alice Eve intercepts and is able to decrypt message It is essential to trust the authenticity of the key

Key Distribution In a public key environment, it is vital that you are assured that the public key with which you are encrypting data, or verifying a signature, is in fact the public key of the intended recipient, or sender, and not a forgery. You could simply trust only with those keys which have been physically handed to you. But suppose you need to exchange with people you have never met; how can you tell that you have the correct key?

Digital Certificates Are an attempt to simplify the task of establishing whether a public key truly belongs to the purported owner. A digital certificate consists of three things: –A public key. –Certificate information. ("Identity" information about the user, such as name, user ID, and so on.) –One or more digital signatures. If you trust the key that signed the certificate, then you trust the key that's in the certificate.

Digital Certificates Process Apply for a digital certificate from a Certificate Authority (CA) The CA issues a signed digital certificate containing your Public Key and other identification information. The CA makes its own public key readily available –In a certificate on your computer, or from a server Senders attach their certificate to signed message along with signature The recipient of the message uses the CA's public key to verify the attached digital certificate as issued by the CA Obtains sender's public key from the certificate. Use public key to verify message signature

Digital Certificate * Certificate o Version o Serial Number o Algorithm ID o Issuer o Validity + Not Before + Not After o Subject o Subject Public Key Info + Public Key Algorithm + Subject Public Key o Issuer Unique Identifier (Optional) o Subject Unique Identifier (Optional) o Extensions (Optional) +... * Certificate Signature Algorithm * Certificate Signature

Certificate Management Small groups of people who wish to communicate securely can manually exchange each owner's public key. –Manual public key distribution Certificate Servers –Storage-only repositories of keys or keys and certificates Public Key Infrastructures (PKIs). –More structured systems that provide additional key management features –Such as revocation

PKI Operations Issuing Dissemination Revocation Expiration Trust Transfer Infrastructure has to support these operations

Examples

Problems? Trust starts with the CA certs loaded into browser by supplier (MS, Mozilla, Google etc) No one wants a browser that can't visit some sites so suppliers want to include everyone Too many CA's some not very good Turk Trust fiasco led to MITM attacks on SSL protected sessions turktrust-fiasco.htmlhttp://erratasec.blogspot.ca/2013/01/notes-on- turktrust-fiasco.html

SSL / TLS

SSL Basics Client/Server Client requests TLS session –Port number (443 for HTTPS) –Protocol specific STARTTLS for mail and newsgroups

SSL Basics Four protocols Handshake protocol  Uses public-key cryptography to establish a shared secret key between the client and the server Record protocol –Uses the secret key established in the handshake protocol to protect communication between the client and the server ChangeCypherSpec protocol Alert protocol

Handshake Protocol Client sends list of supported cipher suites –Cyphers and hash algorithms Server selects strongest it can support, tells client Server sends certificate Server may send cert request if client to be authenticated. Client may send cert Client verifies certificate, uses public key to encrypt random number Sends result to server as basis for symmetric encryption key Client may send signature over previous messages for auth.

Handshake Messages ClientHello ServerHello CertificateRequest –From server if client to be authenticated Certificate ServerHelloDone ClientKeyExchange –With the random number CertificateVerify –With client signature ChangeCipherSpec –Both sides send when finished handshake Finished –Encrypted with new cypher

Other Key Exchange Methods Previous slides assume RSA key exchange –Random number encrypted with key from cert Can also use Diffie-Hellman –Three different versions –Some protect against MITM –By encrypting parameters with key from cert –Or supplying some in the cert –Considered slower so not often used

Record Protocol Other three operate over record protocol Once cypher agreed on, record protocol is encrypted And signed via MAC Application protocol (HTTP) encapsulated in record protocol

SSL/TLS Record Protection Use symmetric keys established in handshake protocol

Key Generation Key exchange establishes one pre-master key Need 6 keys –Symmetric key for encryption –Symmetric key for HMAC (hashing) –IV for CBC Key generation uses pre-master key and random number from client and server with hash functions to generate master key Then keys generated from master key in similar manner

Sessions and Connections Session can consist of many connections Session state includes session ID from server –Plus cypher suite, certs, master key Connection state includes key generation data –Random numbers and six keys –Plus sequence number Session can be resumed by establishing new connection –Easier than new session

TLS Dropped some old cyphers, added some new More complicated key generation More alert types Some messages use simpler hashes

Some sample test questions Which of the following is not a candidate integrity algorithm for SSH? –HMAC-SHA1 –HMAC-MD5 –DES-CBC –HMAC-sha1-96

more In SSH host authentication: –Host encrypts random number with private key and sends to client –Host decrypts random number sent by client –Host signs part of the DH exchange –Host verifies signature sent by client

more The six keys used in SSH transport layer include: –Integrity key, host IV and client public key –Host signature, client IV and DH parameters –Host IV, client encryption key, host public key –Host encryption key, client IV, host integrity key

Lab This Week Creating X.509 certificates and Certificate Authority