Uncertain Certificates

Author: A.R. Peters,

IX. Responsibility

Pitfall 4: dump application security on the infrastructure.

Ultimately, it is applications that generate and exchange data, and to ensure integrity and confidentiality of the data, end-to-end encryption between applications must be arranged. That can be done with a Public Key Infrastructure. However, as is apparent from the things described above, this is often delegated to the infrastructure: the underlying Middleware, transport layer, network.

Organizations are looking for a generic solution. Architects do not want everyone to invent a wheel, and good programmers have a reputation of being lazy, and security is difficult so they like to outsource it and purchased applications do not meet specific local standards anyhow. So a generic solution is being built on the common infrastructure layer. But then there are always gaps in the chain. Moreover the generic solution can never meet specific requirements of an application. The infrastructure cannot know who uses it, what data are exchanged, and who has to be allowed access: all that can only be managed at the level of the application.

If the Security Officer, architects, and application builders are doing things really well, they build end-to-end encryption to ensure data integrity and confidentiality and to allow mutual authentication and authorization. Then the application itself must do PKI. But then it is necessary to distribute the keystore with the private key across all hosts where the application is running.

Pitfall 5: copy private key.

This is not really a pitfall but a design error in the PKI tools IMNSHO. It is necessary to copy the private key, if only as backup, but also for redundancy as described above. But this means that it is also possible to steal the key. There have been appliances for sale keeping the private key in hardware (Hardware Security Module); such a thing often also has a motion detector that destroys the key if someone physically tries to steal the device. But most people use software keys. And bits can always be copied.

So, you should overthink carefully and prescribe it in a Key Management Procedure, who when and how can access a software private key and the truststores, and how to install these securely on multiple hosts; preferably automated. Unfortunately, it will sometimes happen that someone gets root and by hand puts the files wherever they are needed. Then you rely 100% on your employee and 0% on technology.

A better solution is to put the private keys and truststores on a shared disk, and mount it on all nodes that needs it. Then the keys stay in one place. Redundancy / backup is usually taken care of if the shared disk is part of a Storage Area Network.