Richard Henson University of Worcester October 2016 COMP3371 Cyber Security Richard Henson University of Worcester October 2016

Week 4: Public Key Encryption & PKI Objectives Explain public-private key encryption (PKE) Explain need for the sender of data to identify themselves; why digital signatures are necessary in the real world; how they can be implemented Explain PGP and PKI as two reliable techniques for sending data securely from one place to another… including verification of the sender Apply PKE to the sending of secure email

Symmetric v Asymmetric Key one encryption/decryption key only Asymmetric (public key encryption, PKE) encryption: shared public key decryption: unshared private key each algorithm a one way function

Authentication of Transmitted Data Two potential issues with data sending: is it intact & unmodified? (integrity) date/timestamp etc… can original authorship (authenticity) be established i.e. is the sender really is who he/she claims to be Requirements for Authentication: inputs (sender): secret key, message output: message authentication code

When is Encryption alone not enough? On local network covered through username/password network system should verify authenticity BUT… when data is on the move to a computer or device from OUTSIDE the network… It could come from ANYONE…

Authentication Methods Paper correspondence? by physical signature/wax, stamped seal Many available digital methods of providing a sender signature to data e.g. Windows SIGVER (file signing) method of checking incoming files to ensure that they are from a Microsoft approved source Linux uses a similar technique

Security & Wireless Data Wireless media more prone to interception WAP (wireless access protocol) encryption only not enough open access, decryption too easy… Requires authentication as well for safe transmission (best WPA-2) use a known SSID to provide authentication of remote device other devices won’t get access…

Asymmetric (two key) encryption Attributed to Diffie and Hellman (US, ‘76) However, British scientists were secretly working on it much earlier… Ellis, at GCHQ, made the first breakthrough in 1970 Based on two keys: public key - known to everyone private or secret key - known only to the recipient of the message

Mechanism of PKE Jane receives encrypted message John wants to send a secure message to Jane… uses Jane's public key to encrypt the message Jane receives encrypted message then uses her private key to decrypt it Original public key method did not support either encryption or digital signatures… therefore vulnerable to third party in the middle eavesdroppers

Public Key Encryption (PKE) Can work in two ways: private key encryption, public key decryption public key encryption, private key decryption Private key on sender’s computer Unencrypted data Encrypted data Data sent through the Internet Public key on recipient computer Encrypted data Decrypted data Received by recipient’s computer

Public Key Encryption (PKE) The public and private keys must be related in such a way that only the public key can be used to encrypt messages only the corresponding private key can be used to decrypt them In theory it is virtually impossible to deduce the private key if you know the public key

Practical Public Key Encryption systems Include public-private key and authentication of sender Variety of techniques developed: Pretty Good Privacy (PGP) Digital Certificates & Public Key Infrastructure (PKI)

PGP (Pretty Good Privacy) Developed by Philip Zimmerman (early 1990s) official repository held at the Massachusetts Institute of Technology spec for v2.0 at RFC #1991 https://tools.ietf.org/html/rfc1991 Based on public-key method… plus authentication using a “web of trust”. Quote from RFC… “As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.” Convenient way to protect messages on the Internet: effective easy to use free

Using PGP (or not..) To encrypt a message using PGP, the receiver needs the PGP encryption package Zimmerman made it available for free download from a number of Internet sources Such an effective encryption tool that the U.S. government actually brought a lawsuit against Zimmerman! Problem: PGP made public… therefore available to enemies of the U.S.

US gov v Zimmerman (PGP) Actual Lawsuit: selling munitions overseas without a license (used >40 bit encryption) unpopular… after a public outcry, quietly dropped, law changed in 2000 Still illegal to download PGP from US to many other countries

Trust Ever seen the film “Meet the Parents?” https://www.youtube.com/watch?v=8gXyPNUQDvU Web of trust (personal) not practicable for trust “in the business sense” Business Trust “you may not trust me, but you do trust my business enough to accept that you’ll get paid!” PGP web of trust wouldn’t be practicable! New model developed by business (embedded into PKI)

Verisign Trust System Web of Trust (PGP) OK for academics (“good” people?) but bad” people can do business Need for a more practical alternative developed so that people could trust strangers in business transactions financial institutions provide the “trust”

LDAP and Public Key “lookup” Public Key “lookup” developed - system that could be used with PKE Protocol: LDAP (Lightweight Directory Application Protocol) Netscape spec: https://www.ietf.org/rfc/rfc2251.txt “historic” involvement of Microsoft in Internet Infrastructure implemented in VB (!) Microsoft/Netscape/Internet Engineers put all together… Public Key Infrastructure (PKI)

The Public Key Repository Store of public keys so they can only be used securely readily accessible via the Internet and LDAP enabled public key lookup to occur transparently i.e. without intervention from the user Infrastructure complete by 1999 Implemented through Windows 2000 architecture Active Directory many still never heard of it or how to implement it even in 2016!

Digital Signatures/Digital-IDs Unique 'security code' appended to an electronic document the digital equivalent of a signature on a paper document authenticates the sender permits the authenticity of the document to be proven also used the ensure the integrity of the message sent Signature and public key supplied packaged within a digital certificate usually 30-day trial, then ~£100 for 2-year lease

Digital Certificate Randomly generated number that creates, via algorithm: the public-private key pair the attachment to an electronic message known as a digital signature Service for those wishing to send encrypted data (inc email) acquire digital certificate from Certificate Authority (CA)

Certificate Authorities Trusted third-party organizations that issues the digital certificates used to create public-private key pairs Started with Verisign www.verisign.com Many more followed Role of CA: guarantee that the individual granted the unique certificate is, in fact, who he or she claims to be.

Certificate Authorities Authentication.. CA has an arrangement with a financial institution, such as a credit card company finance company provides it with information to confirm an individual's claimed identity Soon became a critical component in security and e-commerce guarantee that the two parties exchanging information really are who they claim to be

Supplying Digital Certificates Online via CA… Digital certificates contain: the applicant's private key a digital signature CA makes its own public key readily available via LDAP digital certificate attached to the message recipient of the encrypted message uses CA's public key to decode the digital certificate

Digital Certificate (continued) The recipient: verifies the digital signature as issued by the CA obtains the sender's public key and digital signature held within the certificate With this information, the recipient can send an encrypted reply

Digital Signatures: an increasing role in society… Increased online delivery of traditionally paper based correspondence & services… contracts government forms such as tax returns anything else that would require a hand-written signature for authentication… Information sent WITHOUT a digital signature… has NOT been authenticated! proof of identity of sender? Should still be FAXed

The trouble with HTTP General Internet principle of “anyone can go anywhere” On a Windows system with www access: TCP can link directly to HTTP session layer authentication not invoked HTML data transferred directly to the presentation and application layers for display Problem: the data is visible to anyone else on the Internet who may have access to that machine and the data path to it!

Secure HTTP and the user authentication problem Makes use of the potential for requiring authentication at the session layer SSL protocol can require a username/password combination before data passes through the socket from transport layer to application layer application authentication required transport

Computer Authentication SSL is able to use the PKI When a user first attempts to communicate with a web server over a secure connection: that server will present the web browser with authentication data presented as a server certificate (remember those?) verifies that the server is who and what it claims to be Works both ways… server may in return request client authentication

SSL and Encryption Authenticating the user & server only helps when the data is at its at its source or destination data also needs to be protected in transit… SSL working at level 5/6 also ensures that it is: encrypted before being sent decrypted upon receipt and prior to processing for display

Is an SSL Digital Certificate Really Necessary? Yes: for sites involved in e-commerce and therefore involving digital payment any other business transaction in which authentication of identity is important No: if an administrator simply wants to ensure that data being transmitted and received by the server is private and cannot be snooped by anyone eavesdropping on the connection In such cases, a self-signed certificate is sufficient

Https & “Web of Trust” Based on individual trust networks built up between individuals Possible to “self sign” a digital certificate if someone trusts you, a self-signature may be all they need OpenPGP identiity certificates are designed to be self-signed

General Tips on Running SSL Designed to be as efficient as securely possible but encryption/decryption is computationally expensive from a performance standpoint not strictly necessary to run an entire Web application over SSL customary for a developer to decide which pages require a secure connection and which do not

When to use SSL Whenever web pages require a secure connection e.g.: login pages personal information pages shopping cart checkouts any pages where credit card information could possibly be transmitted

Running HTTPS Client-server service like http and ftp runs on the Web server uniquely designed so it will not run on a server without a server certificate Once set up, https requires users to establish an encrypted channel with the server i.e. https:// rather than http:// Unless the user uses https… get an error, rather than the pop up that proceeds the secure web page

HTTPs and encryption Even if https channel set up with server certificate, still potential problems use of an encrypted channel running https between user's Web browser and Web server BOTH must support the encryption scheme used to secure the channel e.g. 128-bit RSA

Accessing a Web Page using HTTPS Prefix the address with https:// instead of http:// and the system will do the rest Any pages which absolutely require a secure connection should have a facility to: check the protocol type associated with the page request take the appropriate action if https: is not specified

Proof that Web Page has been delivered securely using SSL At one time.. a pop up would appear… informed the client that they are entering a secure client-server connection must be acknowledged to continue Default browser settings now bring up https page automatically if all is well

A Practical Limitation on the Use of SSL SSL “handshake”, where the client browser accepts the server certificate, must occur before the HTTP request is accessed As a result: the request information containing the virtual host name cannot be determined prior to authentication it is therefore not possible to assign multiple certificates to a single IP address name-based virtual hosts on a secured connection can therefore be problematic

Next session will explore… Authentication and access control to websites, remote organisational servers It will also introduce Active Directory and Firewalls