25

I'm about to implement my own Certification Authority (CA) for interal use only.

Now there is a problem, that the CA private should never ever be exploited. So right now the private key is encrypted.

What else could be done to enhance the security of the private key?

Ben Pilbrow
  • 11,995
  • 5
  • 35
  • 57
JMW
  • 1,451
  • 4
  • 19
  • 27
  • Can we get OS you are running the web server on? You probably could set the permissions on the file so that it is not readable by anybody except by the app as well as the superuser. – Rilindo Sep 03 '11 at 15:58
  • we're running RHEL – JMW Sep 12 '11 at 14:53

5 Answers5

26

I worked at a company where the security of the CA key was critical to the continued success of the business. To this end the key was encrypted using a custom protocol that required at least 2 people to be present with physical tokens plugged into terminals to decrypt it(there were at least 5 of these tokens, any 2 combined would work). The terminals were physically separated from the actual machine with the CA key. The interface that the users had who decrypted it was a VT220 terminal that allowed them to input the decryption tokens and then select what they wanted to 'sign' with the key (never giving them access to the decrypted key). This system meant at least 4 people would have to work together to compromise the key, two token holders, the guy who had access to the data center, and another person who had root access on the server (because the decrypted key was never stored on the server only in memory you couldn't just steal the box, and the people with root to this specific server were not allowed DC access).

If you are interested in more details on this sort of setup Bruce Schneier has a great site covering computer security design and implementation:

http://www.schneier.com/

He has also published a really good book Applied Cryptography that I found helped me understand the fundamentals of systems like this and how to architect more secure infrastructures (readable by people who don't wear pocket protectors):

http://www.schneier.com/book-applied.html

polynomial
  • 3,968
  • 13
  • 24
  • 2
    And two-key operation (or any n from m, m>=n, n>1) is another excellent precaution - but for my money, airgap first, and add refinements like this second, depending on your degree of paranoia (ie, the cost of failure). – MadHatter Sep 03 '11 at 17:31
  • 1
    Why can't the person with root access dump the contents of memory to a file while two authorized people are doing their job? This means that the guy with root can get the key with only the additional resources required to get the memory dump off the machine. – Slartibartfast Sep 03 '11 at 21:58
  • Audited physical access control is as important to this kind of security as audited logical access control. The signing operation shouldn't require privilege on the box (that control is handled by the any-n-from-m requirement), so the root password holder shouldn't be there **at all** when keysigning is going on. (S)he will be needed for system maintenance activities, but these should be carried out according to a precise pre-written script, by someone other than the script writer, and real-time audited by a knowledgeable third person. – MadHatter Sep 04 '11 at 12:23
16

One big gain is to keep the private CA key on a dedicated computer completely cut off from the network. You would then sign, and possibly also generate, new certificates on this machine, and then use an physical media to transfer the new certificates off the CA machine.

Such as setup would of course also include considerations regarding the physical availability of the machine, as well as restrictions on allowed medias. A well traveled USB stick is probably not the best of choices...

(This is by the way a very clear example on the trade off between security and convenience.)

andol
  • 6,848
  • 28
  • 43
  • Airgap is an excellent security precaution, and the danger of removable media can be mitigated by setting the signing box not to autorun anything, permit SUID binaries or in any other way trust *executables* on such media. – MadHatter Sep 03 '11 at 17:28
  • This can be further optimized by using a smartcard to generate, store and use the key. Think of a smartcard as a dedicated machine that has some protections against tampering (basically, the chip would rather break than give up the key, which is difficult to do with a more complex system) and that has an interface that is simple enough that the protocol stack could have been audited properly. – Simon Richter Sep 03 '11 at 18:18
  • I second the smartcard suggestion, but there is a risk there. When the key is only able to be in one place, only one piece of hardware needs to fail to cause the key to be inaccessible. I think one or more smartcards could form an important part in a secure key generation and storage practice though. – Slartibartfast Sep 03 '11 at 22:02
  • Regarding the autorun issue. In case of a gui file manager, it might also be advisable to be explicit about it not trying to do do any smart previews/thumbnails of listed files. While not a danger in itself it can be an attack vector to existing vulnerabilities. – andol Sep 03 '11 at 23:10
  • If security is really important, I'd go with a bunch of write-once CD-R. – Lie Ryan Sep 03 '11 at 23:20
15

I have upvoted the other two answers, and commented thereon, because I think they're both excellent. If you decide to go for both of them, and that might well be appropriate, I strongly advise care in the initial generation of the key, since the best time to compromise a key is not in use (where many standard, repeatable precautions can be applied) but at generation time, which being a once-off is much easier to subvert.

This excellent guide to conducting a key-generation ceremony outlines some of the standard protocols that can help to secure key generation, though they mostly boil down to (a) having everything witnessed by multiple knowledgable auditors, who are (b) making contemporaneous records of everything that is done (c) according to a pre-determined protocol written by someone other than the executor.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
7

Depending on how serious you are, you should consider using FIPS 140-2 (http://en.wikipedia.org/wiki/FIPS_140#Security_levels) hardware to store CA keys and back-ups of those keys. You should have one root CA and one intermediate CA so you can keep your root CA offline and physically secured. The root is only needed to renew or sign new intermediate CAs, whereas the intermediate CAs stay online for day-to-day operations. As others have suggested, secure key generation and key management with n of m control is important.

The VeriSign (now Symantec) CPS is a good reference for how a commercial CA generates and protects its keys. Look at chapters 5 and 6, specifically: http://www.verisign.com/repository/cps/. (I worked at VeriSign for several years)

Also, NIST has several good publications on Key Management (http://csrc.nist.gov/publications/drafts/800-57/Draft_SP800-57-Part1-Rev3_May2011.pdf) and generation, and your company should also have a CPS that specifies the policies and practices you use for managing your CA. The IETF provides a good template: http://www.ietf.org/rfc/rfc2527.txt

Perry
  • 71
  • 1
1

Great question and some great answers too.

Keep in mind that you're about 90% ahead of most other people simply by considering this issue rather than blindly charging ahead.

Having kept that in mind and taken the other advice here, I would simply add: don't rest on your laurels; keep an eye on security and cryptography news for both general issues relating to certificate issuing, revocation, cracking, etc. and most definately on vulnerabilites and issues with the specific products you use to generate and manage your keys.

Lastly: physical security. Making something 'hacker proof' is no help if I can just get a job as a contract cleaner in your building and then put the disk containing your root cert in my pocket one day. You'd be surprised how many people miss that one.

Rob Moir
  • 31,664
  • 6
  • 58
  • 86
  • Glad to hear it @jmw - like i said, you're already ahead of 90% or maybe even 99% of most people, and it sounds like you've got it all in hand. You would be shocked at the amount of people who spend weeks and tonnes of money looking at the software side of things without doing anything to physically secure the data. – Rob Moir Sep 12 '11 at 16:03
  • Thanks, you're absolutely right: staying informed about new risks is mandatory for every admin. :-) about physical security: the datacenter, where our servers are, has a high physical security. thus there are bios && grub passwords configured. the partition where the CA stuff is stored is also encrypted. furthermore the CA key itself is encrypted. And nagios would trigger "server down" alerts in case of a physical theft. I'm more concerned about "non-physical" exploits. :-) – JMW Sep 12 '11 at 16:07