2. COMP3371 Cyber Security Richard Henson University of Worcester October 2015

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

4. Symmetric v Asymmetric Key n Symmetric  one encryption/decryption key only n Asymmetric (public key…)  encryption: shared public key  decryption: unshared private key  each algorithm a one way function

5. Authentication of an Email Message n Two potential issues with new email:  Is it intact & unmodified? (integrity)  can original authorship (authenticity) be established n Requirements for Authentication:  Inputs (sender): secret key, message  output: message authentication code

6. When is Encryption alone not enough! n Authentication:  technique needed for verifying that the sender really is who he or she claims to be n On local network  covered through username/password n When data is on the move to a computer or device from OUTSIDE…  could come from ANYONE!

7. Authentication Methods n Paper correspondence?  by physical signature n Many available digital methods of providing a sender signature  e.g. Windows SIGVER (file signing) »method of checking incoming files to ensure that they are from a Microsoft approved source  Java now uses a similar technique

8. Security & Wireless Data n Encryption (e.g. WPA) not enough  open access  decryption too easy… n 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…

9. Asymmetric (two key) encryption n Diffie and Hellman (US, 1976)  British scientists were secretly working on it much earlier  Ellis, at GCHQ made the first breakthrough in 1970 n Two keys:  public key - known to everyone  private or secret key - known only to the recipient of the message

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

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

12. n 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 n In theory it is virtually impossible to deduce the private key if you know the public key Public Key Encryption (PKE)

13. n Include authentication of sender in architecture n Variety of techniques developed:  Pretty Good Privacy (PGP)  Digital Certificates & Public Key Infrastructure (PKI) Practical Public Key Encryption systems

14. PGP (Pretty Good Privacy) n 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 https://tools.ietf.org/html/rfc1991 n 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.” n Convenient way to protect messages on the Internet:  effective  easy to use  free

15. Using PGP (or not..) n 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 n Such an effective encryption tool that the U.S. government actually brought a lawsuit against Zimmerman! n Problem:  PGP made public…  therefore available to enemies of the U.S.

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

17. Trust n Ever seen “Meet the Parents?” n Web of trust (personal) not practicable for trust “in the business sense” n New system needed that followed “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!  Different model needed…

18. LDAP and Public Key “lookup” n One of flaws with single key encryption…  getting the key securely to the receiver n An alternative approach to the “web of trust” the creation of an Internet lookup system that could be used with PKE  became known as LDAP (Lightweight Directory Application Protocol) »Netscape spec: https://www.ietf.org/rfc/rfc2251.txt https://www.ietf.org/rfc/rfc2251.txt  “historic” involvement of Microsoft in Internet Infrastructure »implemented in VB n System expanded rapidly to form Public Key Infrastructure (PKI)

19. The Public Key Repository n Store of public keys associated with authentication data  readily accessible via the Internet  included a set of “lookup” protocols known as LDAP (Lightweight Directory Access Protocol)  enabled public key lookup to occur transparently i.e. without intervention from the user n Infrastructure complete by 1999  many still don’t know of it or how to implement it even in 2015!

20. Digital Signatures/Digital-IDs Unique 'security code' appended to an electronic document 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 n Signature and public key supplied packaged within a digital certificate  usually 30-day trial, then ~£100 for 2-year lease

21. Digital Certificate n A randomly generated number:  used to create the public-private key pair  creates the attachment to an electronic message known as a digital signature n Anyone wishing to send an encrypted email message for a digital certificate from a (CA) Certificate Authority

22. Certificate Authorities n Example: verisign  www.verisign.com www.verisign.com n Trusted third-party organizations that issues the digital certificates used to create public- private key pairs n The role of the CA is to guarantee that the individual granted the unique certificate is, in fact, who he or she claims to be.

23. n Usually, this means that the 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 n CAs are a critical component in data security and e-commerce because they guarantee that the two parties exchanging information really are who they claim to be Certificate Authorities

24. n On request, a CA can produce an encrypted digital certificate for any applicant n Digital certificates contain:  the applicant's private key  a digital signature n CA makes its own public key readily available on the Internet n The recipient of the encrypted message can use the CA's public key to decode the digital certificate attached to the message Supplying Digital Certificates

25. n The recipient:  verifies the digital signature as issued by the CA  obtains the sender's public key and digital signature held within the certificate n With this information, the recipient can send an encrypted reply n This procedure relies on the integrity of the CA, and the user must be able to trust them Digital Certificate (continued)

26. Digital Signatures: an increasing role in society… n 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… n Information sent through the Internet WITHOUT a digital signature…  has NOT been authenticated!  further means of proof of identity of sender should be sought… could be FAXed

27. The trouble with HTTP n General Internet principle of “anyone can go anywhere” n 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 n Problem:  the data is visible to anyone else on the Internet who may have access to that machine and the data path to it!

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

29. Computer Authentication n SSL is able to use the PKI n 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 n Works both ways…  server may in return request client authentication

30. SSL and Encryption n 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… n SSL working at level 5/6 also ensures that it is: »encrypted before being sent »decrypted upon receipt and prior to processing for display

31. Confidentiality & Integrity n Encryption of SSL responses can be  Either Standard 40 bit RSA »difficult to break confidentiality  Or Secure 128 bit RSA »virtually impossible to “crack” n Guarantee that the data will not be modified in transit by a third party  integrity therefore also maintained

32. Is an SSL Digital Certificate Really Necessary? n Yes:  for sites involved in e-commerce and therefore involving digital payment  any other business transaction in which authentication of identity is important n 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

33. Https & “Web of Trust” n Based on individual trust networks built up between individuals n 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

34. Verisign Trust System n Web of Trust  OK for academics (“good” people?)  but bad” people can do business n Verisign system presented as an alternative  developed so that people could trust strangers in business transactions  financial institutions provide the “trust”

35. General Tips on Running SSL n 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

36. When to use SSL n 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

37. Running HTTPS n Like http and ftp, a client-server service that runs on the Web server  uniquely designed so it will not run on a server without a server certificate n Once the service has been set up, https will require users to establish an encrypted channel with the server  ie https://  rather than http:// n Until the user does use https they will get an error, rather than the pop up that proceeds the secure web page

38. Running HTTPS n However, there still could be problems with access… n The use of an encrypted channel running https requires that the user's Web browser and the Web server BOTH support the encryption scheme used to secure the channel n For example:  IF an IIS Web Server is set to use default secure communication settings  THEN the client Web browser must support a session key strength of 40 bits, or greater

39. Accessing a Web Page using HTTPS n If the client is to request a page that needs SSL:  in the HTML code that will call that page, prefix the address with https:// instead of http:// and the system will do the rest n Any pages which absolutely require a secure connection should:  check the protocol type associated with the page request  take the appropriate action if https: is not specified

40. Proof that Web Page has been delivered securely using SSL n The first thing is that (depending on browser settings) a pop up appears…  this informs the client that they are entering a secure client-server connection  The pop up must be acknowledged to continue n The page will then be displayed:  https:// will appear before the URL  “lock” symbol appears on the bottom left of the screen

41. Practical Limitations on the Use of SSL n The SSL “handshake”, where the client browser accepts the server certificate, must occur before the HTTP request is accessed n 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 n Using name-based virtual hosts on a secured connection can therefore be problematic

42. Authentication Types/Factors n Classified 1, 2, or 3 n Type 1: Knowledge based (what user knows)  information provided based on person’s unique knowledge n Type 2: Token based (what user has/does)  information comes from a token generated by a system »tied in some way to the user logging on  generally not considered a good idea on its own because someone else could have stolen/copied it n Type 3: Characteristic based (what user is)  biometric data from the person logging in

43. Which to use? n Ideally all three! n At least 2 factors recommended:  e.g. password or PIN number (type 1)  card based record (type 2) n For best security…  Type 3 retina scan or fingerprint (AS WELL!)

44. One time Passwords (OTP) n Can only be used once…  If user gets it wrong, becomes invalid… »locked out »has to contact administrator to reset n Implemented as a type 2 factor  password characters randomly generated n If used properly…  very secure indeed  problem: degree of randomness…

45. 1/2/3 factor authentication & Identity Theft n Factor 1 authentication alone is not enough  username/password may be stolen (or even borrowed with permission!) n Need proof:  something only that person would know…  something unique to that person Biometric data) n More on this later…

46. Single Sign On (SSO) n Logon once…  authenticated for all servers in that environment n More a convenience matter than a security issue  only one set of authentication factors needed  single username/authentication factor database covering all servers n SOME very secure environments have dropped SSO in favour of separate logon for each server  arguable whether this is necessary but avoids the “all eggs in one basket” argument

47. Password Administration n Three aspects:  Selection »should be a company IS policy that includes choice of password »generally no. of characters is a good match with strength – the higher the better  Management »selection & expiration period must comply with policy  Control »policy should be enforced by the network itself »usually achieved through use of “group policies”

48. Access Control Techniques n Discretionary (DAC)  access to files/resources controlled by system administrator  Achieved through ACLs (Access Control Lists) »consist of ACEs (Access Control Entries)  the granting of access can be audited n Mandatory (MAC)  access dependent on rules/classifications  classification: »hierarchical or compartmentalised, or hybrids »dependent on security clearance levels

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