S.E.E. PKI - Attack scenarios

Attack scenarios

During the 1999 annual CSI conference in Washington DC, Dr Fred Cohen - a widely published US computer security researcher and consultant - introduced a list of PKI attack scenarios titled "50 Ways to Defeat Your PKI and Other Cryptosystems".

The 50 scenarios are listed below, each followed by recommendations to minimise or eliminate the risk in the S.E.E. PKI. Note that this is not intended to be a comprehensive list of all attacks, but it does provide a good indication of many areas of potential vulnerability.

How the S.E.E. PKI addresses the risk of attack

Attack 1. Flood the PKI with fictitious user IDs and names. The net effect is that any typo gets the user one of your pre-positioned keys. You then decrypt their messages and forward them encrypted to the intended recipient.

Response: This risk can be eliminated by the approved CAs having strict registration requirements for Subscribers, including proof of identity and authorisation for use of a specific DN and e-mail address.

Attack 2. Interrupt traffic every 10 or 20 packets by sending a 'reset' packet to the session. Since PKI uses private key encryption for high volume transmissions, it depends heavily on synchronization for its proper operation. Every time you desynchronize the private key system, new public key exchanges have to be make to get a new private key - at the overhead of lots of computer time and exchanged bits. The system will rapidly become unusable.

Response: This is not strictly a vulnerability of the PKI, but of the application using the PKI. It is a standard denial-of-service type of attack those variants could potentially affect many applications that may or may not use PKI and / or encrypted channels.

Attack 3. Buy a public key under a phoney name and start sending viruses with a signature that is traceable to the fictitious identity. Since key revocation works so poorly today, this will likely be trusted for a long time to come.

Response: As with Attack 1. The proposed S.E.E. PKI architecture will also mandate the creation and checking of CRLs as a minimum, moving to online status checking when and where possible.

Attack 4. Buy a new phoney public key every few hours and send viruses with them all.

Response: As for Attack 3.

Attack 5. Put a Trojan horse in a Word document to send out the users' private key file. Actually, this was done earlier in 1999, so it's not an original idea.

Response: All Subscriber crypto-modules should be FIPS140 evaluated. The crypto-module, including the key store, should be contained on a token (e.g. a smart card). Alternatively, encryption of the key store will make the stored keys less vulnerable, but will not protect against copying the keys out of memory. This risk should be reduced by appropriate network and operating system controls on S.E.E. computers and user awareness of the risks involved with processing executable files.

Attack 6. Put a virus in a Spread Sheet that sends out the users' private key file. S.E.E. #5 above.

Response: As for Attack 5.

Attack 7. Break into the user's computer by exploiting some other weakness and forge their private key use.

Response: As for Attack 5.

Attack 8. Break into a user's system and listen to their keystrokes as they type in the password used to reveal their private key (for systems that protect the private key file with some other form of cryptography).

Response: As for Attack 5.

Attack 9. Guess the password on the 'locked' private key file stolen with one of those techniques above.

Response: As for Attack 5.

Attack 10. Use a Trojan horse to disable cryptography without telling the user about it, so that it looks like it is encrypting when it is not.

Response: Not applicable for Authentication certificates. Where encryption is required, the user application should be set up to notify the user if the communications is going out unencrypted.

Attack 11. Revoke the key of a user who is still using their key. This will cause them to have to re-register again and again and confuse the whole system over time.

Response: The S.E.E. PKI standards will require any request for revocation of a certificate to be authenticated. Only the Subscriber, the certificate Sponsor, the RA, or the CA can initiated revocation.

Attack 12. Get people to encrypt things you provide them, and use it to get their private key. This was demonstrated to work in the early 1980s.

Response: S.E.E. PKI certificates will only be used to authenticate to NZ Government systems. Therefore, the Government system would have to be compromised before this attack could be mounted.

Attack 13. Break into a server that stores public keys and change them to ones you specify.

Response: The public keys are stored in signed X.509 certificates. If the attack goes unnoticed by the directory administrator, Relying Parties will quickly notice it as they attempt to use the certificates.

Attack 14. Get into the Internet's DNS system and change the apparent location of the various key servers on the net. The whole PKI system will break down as no servers can be found anymore to verify anything.

Response: Compromise of DNS servers will affect the operation of the Internet, regardless of whether PKI is used or not.

Attack 15. Crash a few key servers that form the base of the PKI tree for the users' you want to defeat and they will be unable to communicate except in plaintext.

Response: Crashing one or more of the CAs will not affect use of the PKI, unless they cannot be repaired before the current CRLs expire and new ones cannot be issued.

Attack 16. Observe the time taken to do encryption using peoples' private keys and analyze the time differentials for different things encrypted to derive the private key bits.

Response: This attack has been proven in lab conditions against a smart card system where the attacker had physical access to the smart card. It is unlikely to be effective across the Internet.

Attack 17. Use network time protocol forgeries to make some cryptosystems get desynchronized. The overall effect for many key servers is that they will no longer trust other servers and refuse to communicate with them.

Response: S.E.E. firewalls will be configured to disallow such protocols to pass between the Internet and internal systems.

Attack 18. As initial key distribution is done, place an attacking machine between the machines exchanging keys and do a man-in-the-middle attack to make each think you are the other. You will now be permanently in the middle of all their communication.

Response: This attack is not valid against properly named and authenticated public key certificates.

Attack 19. Use a van-Eck attack to observe the 'secret' messages before they are encrypted.

Response: This is another name for TEMPEST, the capture and recreation of compromising emanations. The level of protection provided by the S.E.E. PKI is not intended to protect against attacks of this sophistication.

Attack 20. Use a van-Eck attack to observe the 'secret' messages after they are decrypted.

Response: As for Attack 19.

Attack 21. Use video-viewing to observe the keyboard of the user as they type in their keys.

Response: If an attacker went to this level of effort, they could get the user's password/pin, but this would not compromise the private key unless the attacker also have the private key file or token.

Attack 22. Use video-viewing to observe the keyboard of the user as they type in their messages.

Response: This is not a PKI issue, if the attacker already has this capability they do not need to break into the S.E.E..

Attack 23. Put a fake keyboard adapter between their keyboard and computer and pick up the keys and messages as they are typed.

Response: As for Attack 21.

Attack 24. Break into the manufacturer of the PKI system and place a Trojan horse into their system. Nobody will ever find it.

Response: The S.E.E. PKI should use products that have been evaluated under AISEP or a similar scheme whenever possible. Independent inspection of the source code is the only way to have a reasonable level of assurance where are no dangerous Trojan Horses or Easter Eggs in the product.

Attack 25. Pay the companies to put in a Trojan horse.

Response: As for Attack 24.

Attack 26. Force people to use key escrow, and then break the escrow system through legal or extralegal means.

Response: Key escrow is not applicable for Authentication certificates.

Attack 27. Limit key length to only a few hundred bits of key. The government exploited this one for a long time - and still does.

Response: The S.E.E. PKI will use a minimum of 1024 bit RSA keys.

Attack 28. Create a false distribution of a PKI system and put it into the infrastructure as a replacement for the original. Then people will download the Trojan version and think they have the real thing. The 'self-authentication' will of course claim it is legitimate.

Response: The attack will not be successful as long as the Root keys are passed to users in a trusted out-of-band manner and placed into tamper-resistant key stores.

Attack 29. Create a clever new crypto-algorithm that has a real subtle backdoor and get lots of people to use it. You will be able to exploit it while everyone thinks it's secure.

Response: The S.E.E.E PKI will be using approved symmetric (Triple-DES / AES), asymmetric (RSA) and hashing (SHA-1) algorithms.

Attack 30. Use a parallel processor to break keys of limited length. This has been successful against systems of current common key lengths.

Response: This form of attack is extremely unlikely to be successful against 1024-bit RSA keys in the medium term future.

Attack 31. Write a computer virus that implements a massively parallel cryptoanalysis engine for breaking private keys. Distribute via the Internet.

Response: While this is a possible form of attack, it is unlikely that an attacker would go to the effort just to access a S.E.E. system.

Attack 32. Modify the pseudo-random number generator used by the cryptosystem to generate keys so that they are relatively easy to guess. Previous systems had poor random number generators so that modification was not required.

Response: AISEP evaluated CA and end-user PKI products should be used. Where possible any random numbers, or S.E.E.ds for random numbers, should be generated using GCSB-approved generation modules.

Attack 33. Find a weakness in the random number generator used today by a popular system and guess lots of real keys in use today. It's a good bet you can do this if you are smart enough.

Response: As for Attack 32.

Attack 34. Cause the systems that generate the pseudo-random numbers to have less randomness than they are assumed to have. Then they will generate poor random numbers without having to do anything special.

Response: As for Attack 32.

Attack 35. Generate new private keys for users and plant Trojan horses in their system to have the new keys registered without their knowledge or consent. They you will have a copy of the private key.

Response: The 'shared secret' between the CA and Subscriber and the registration processes should ensure that this form of attack is unlikely to succeed.

Attack 36. Generate gobs and gobs of public key traffic and overload all the servers with requests so that the whole system grinds to a halt.

Response: This is a denial-of-service attack against the network, not against the PKI.

Attack 37. Generate millions of public keys (they don't even have to be legitimate) and push them into key servers to cause them to run out of space and become slow at finding keys.

Response: The directory access controls should allow only CAs and administrators Write privileges.

Attack 38. Corrupt the private key distribution packets used to encrypt sessions so that private keys are wrong.

Response: This is not applicable to Authentication certificates. It is applicable to Encryption certificates, but it is a denial-of-service attack against the network, and is not peculiar to PKI protocols and cryptographically protected channels specifically.

Attack 39. Disrupt the private key distribution process so that session keys cannot be distributed.

Response: As for Attack 38.

Attack 40. Replay private key distribution in place of interrupted distribution to force old keys to be reused, thus making these sessions easier to break.

Response: This is not applicable to Authentication certificates. It is applicable to Encryption certificates, but will not be successful because the key negotiation will fail.

Attack 41. Store sessions and break them over a long period of time. For most current systems, all of the content will be readable within a few years with parallel processors. For many you can read them today if you spend enough time and effort.

Response: This is a symmetric encryption issue, so is not applicable to Authentication certificates. In general, the information passed between S.E.E. systems will not be sensitive for more than 2-3 years and should not attract such a determined attack.

Attack 42. Bribe the person who is using the key to get access to the private key.

Response: This is a user-awareness and liability issue. The Subscriber conditions of use will state the expectations and requirements on the users. Auditing and intrusion detection on S.E.E. systems should detect attempted use of the S.E.E. certificate to gain access to systems the original Subscriber is not authorised to access.

Attack 43. During the electronic distribution of the cryptosystem, corrupt a byte and watch the distribution fail. Do this again and again and the system will fall into disrepute.

Response: The cryptosystems will be distributed and installed locally, not downloaded across the Internet.

Attack 44. Create a false update for the cryptosystem and send it out to users. When they load the update, it contains a Trojan horse that defeats the system.

Response: As for Attack 43.

Attack 45. Most data exchanged via encryption is stored in plaintext. Get access to the database where they store the information at either end and defeat the value of the cryptosystem in assuring the confidentiality and integrity of the underlying data.

Response: S.E.E. systems will be protected from unauthorised access from the Internet by appropriate network, operating system and application mechanisms and configuration.

Attack 46. Find one of the many flaws in the cryptographic protocol used to do key exchange and private key distribution and exploit it to defeat the cryptosystem. Current cryptographic protocols have been found to have many vulnerabilities.

Response: The S.E.E. Governance Board will ensure departments are kept informed of any new vulnerabilities and fixes in the systems used within the S.E.E. security infrastructure.

Attack 47. Convince the user to misuse the cryptosystem - for example - to use a weaker cryptosystem because it's faster.

Response: As for Attack 43.

Attack 48. Corrupt the browser via a Trojan horse so that it makes it look like the cryptosystem is in use when it is not. For example, make the lock appear to be locked in Netscape.

Response: The workstation access controls, S.E.E. network protection, and user-awareness of the dangers of downloading executable files should make this type of attack unlikely to succeed.

Attack 49. Break into the certificate server and take the master certificate. Then you can subvert the whole system without anyone knowing about it.

Response: This must be referring to the CA private key, not the certificate. S.E.E. PKI CAs will have strict guidelines on protection of their signing mechanism and private keys.

Attack 50. Publish an article on 50 ways to defeat your PKI and cryptosystem, thus eroding public confidence in PKI and making the system less trusted from a public perception perspective. I think I have done that by now.

Response: This attack will be counteracted by the confidence generated by the S.E.E. PKI assurance programme.