Two-factor authentication means that you have authenticators from to different classes of authenticator:
- What you know, like a password or pass phrase.
- What you have, like a OTP Token or a smart card.
- What you are, like a fingerprint, voice print, keystroke rhythm.
Why would you even want a second factor and why from a different class?
We don't want more security! If we use a send factor, an attacker has something else to get in order to impersonate the legitimate user. However, if the user can get the first factor, then you surely don't want to use one just like it. Different classes of authenticators have different threat models, attack vectors and vulnerabilities. If the attacker can steal one password, they can surely steal a second. They just do what they did, for a bit longer.
If an attacker has to somehow get my password and steal my physical token without me knowing, that's a tall order. You can get my password remotely, but you have top travel and sneak to get my token. On top of that, I carry a Spyderco Delica. That's how I spell compensating control.
The intent of the "what you have" factor, in my opinion, is that the authenticator be a physical object that can not be easily duplicated. This maintains the threat model and the Spyderco control. The "what you have" factor should be hard to copy even if the legitimate owner is colluding. "Here, have a copy of my certificate and private key", should not be an option. If the what you have can be transmitted electronically, it's not a true what you have.
Software certificates and the corresponding private keys, that are stored in some sort of non-volatile storage, i.e. your hard drive. I'll focus on windows boxes, as I can speak very accurately about them, but the following is true with any OS. If the users have physical access to the computers, then they can get admin rights, which means that they can get the private key for the certificate. Don't believe it... Remember, if you have physical access to the box, you own the box. Did you think that your whole disk encryption product could protect you? Take a look at cold boot attacks.
Once you have admin rights, there are two methods to get the private key. The private key is stored in the registry and file system. It's obfuscated a bit and protected with DPAPI, in the machine context. This means that an admin can export the private key. Wait, you've marked the private key as not exportable! Remember, the admin owns the box. The key is there, a piece of code is just telling the system to not hand it over. Let's look at C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\My\Certificates and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\My\Keys
These are all linked together to protect you from getting the key. If we take a look in one of the key files, we see an Export Flag. In this case, local software is reading that flag and choosing whether or not to respect it. Once could just use a little magic and pull out the key. Enter the ninjas at ISEC Partners and their Jailbreak. Give it a shot, and you will see that you can export the key!
So, if the user colludes, copying the software certificate is trivial. If the user is just negligent, the attacker could ghost (clone) the drive and then get access later. If the user is negligent, but uses a good full drive encryption product, the attacker will need some time with the computer to get the key.
Protections of Certificates and Keys That Work
My examples above are related to machine certificates. Those are the only ones that can be used for IPSec, in most cases. If your user does not collude with the attacker and cant' be tricked into running their attack code, (that seems unlikely, users will click on anything) then user certificates are secure. Why? User certificates are protected by DPAPI in the user context. This means that they private key can only be decrypted if the user has typed in their password. The system does not escrow the key for the user, the user's private keys are protected with a key that is derived directly form the password using PKCS 7. If the actual password is not available, their is no way to recover the key. In a workgroup, this is absolute. If the machine is domain joined, an administrator of the domain can reset the user's password and reconnect the machine to the domain and the key can be recovered. Collusion by your domain admins is a whole lot more worrisome than your user.
Whole disk encryption that requires keys stored on a smart card or token can stop most attacks. The problem with most whole disk encryption implementations is that they are not actually secure. They just keep the dumb and honest honest. If you can boot the PC without entering a pass phrase or insert a token, then your disk encryption keys are stored locally and can be accessed by your boot loader. This means that it's just a matter of understanding how that works to get the key, or one can let the machine boot and then use the cold boot method to get the key from RAM. Use real encryption, get a token or smartcard!
One could also use SYSKEY in mode 2 or 3. This encrypts some of the SAM using a key that is derive from a password or on a floppy disk. Neither of these is particularly manageable on an enterprise scale. Most users will leave the floppy in the drive and the password has no rotation policy. Either you have to track it per PC or have a universal password for your org, which will surely get out.
So, if you have a software certificate and private key, they are electronic assets with many avenues that can allow an attacker to copy and electronically copy and transmit them. While the attack vectors for getting the private key differ from getting the user's password, the spirit of "something you have" is not met by a software certificate. This is not to discount the value of software certificates in many situations, they are great. I simply am making the point that they are what they are and one should never forget.
