Skip to content.
|Networking government in New Zealand.
 
You are here: Home » Services » SEEMail » S.E.E. PKI: Paper 2 - Public Sector, Private Sector and Offshore CAs » 11 Appendix A - Attacks and risk management

11 Appendix A - Attacks and risk management

11.1 Potential attacks by a CA

11.1.1 A CA may provide key escrow or backup services. This service is attractive to agencies that do not have the processes, physical security or desire to perform this function. With access to private keys, a CA could take on the precise digital identity of an individual for example to gain access to a secure system, or in the case of confidentiality certificates, decrypt information destined for that individual. This sort of attack would be extremely difficult to detect.

11.1.2 Even without access to keys, a CA has the potential to masquerade as an individual by generating new keys and creating new certificates but with the same details for the individual. This attack would also be difficult to detect.

11.1.3 A CA can create a denial of service attack through Certificate Revocation Lists (CRLs) by not producing them on time, revoking certificates that are valid, slowing access to lists, or creating extremely large lists. This attack would be reasonably obvious to system administrators and users, but could sometimes be difficult to prove.

11.1.4 An attack could be launched on a system by first compromising a CA and then performing one of the above attacks.

11.2 Mitigating risk

11.2.1 We can mitigate the risk of improper key usage (11.1.1) by requiring that agencies create and manage their own key material (something many will want to do anyway). Apart from low cost savings, it is hard to argue that we should permit backup of the private keys for authentication and digital signature certificates anyway. We may decide that some CAs could be allowed to manage key material but not others, for example we might say that private keys should not leave the country. We could also manage this risk by providing a government owned key management service.

11.2.2 We can only manage the risk of masquerading (11.1.2) through using a CA with good process management and staff vetting. It would also be possible to avoid this by relying on specific public keys but this loses the benefits of a PKI, complicates administration and forces a specific architecture on applications.

11.2.3 CRL denial of service attacks (11.1.3) are unlikely as the act is obvious.

11.2.4 A CA must have firewalls and intrusion detection systems to minimise the risk of an attack to, or through, their infrastructure.


[ Previous ]