1

I'll need to use an hardware token, specifically the SafeNet eToken 5110 that comes with DigiCert's EV certificates, for code-signing on Windows.

I know that they issue a prompt to manually enter the token's password at each signing attempt (or at each session, if you enable the single logon option).

I wonder:

How safe are those prompts from keylogging or other password interception techniques?

And thus how much would I increase security by really filling those prompts manually vs. automating them with methods such as those listed here ?

I know that by automating the process I would increase the attack surface, by the fact that the password will probably be stored on disk and for sure on various additional memory locations, but I have a feeling that these software password prompts are nonetheless mostly "security theater", and that there are easy ways to intercept the password (and thus have it later entered programmatically by a malicious program) even if manually typed .

Here I assume that the computer where the token will be used will be an up-to-date Windows 10 system reasonably hardened, so for sure at least not running under an administrative account. It certainly won't be fully isolated though (one way or another I'll have to pass the files to be signed to the system).

EDIT:
I realized that this environment description might be too vague, if that's the problem for the time being we can assume instead a fresh Windows 10 installation, running under a limited account, with decent passwords for that and the administrator's account, connected to the internet through a lan and let's say even joined to a domain.
The rest of the lan is not to be considered really safe.
Let's just add that Windows' privacy options have been all set to deny, just to take out the possibility that Windows sends out the password to its servers to "improve typing", which wouldn't surprise me too much.
I'm not concerned about physical attacks here.

I found the eToken 5110's FIPS 140 security policy. I gave it a quick look but I didn't get too much from it, it doesn't seem to be concerned with the part of the password entry from its typing to when it gets sent to the device.

I think (but not 100% sure) that it is a USB CCID device and that it uses the Microsoft Class Drivers for USB CCID Smart Cards, and that this entails that the password entry is handled mostly by the operating system, rather than by code from the vendor (but again not 100% sure).

gbr
  • 260
  • 1
  • 7
  • 1
    "How safe is **x**?" is not a very realistic type of question to ask. An answer could be "It is ninety two-er and three fifths more secure than insecure!". Makes about as much sense as the question. You have laid out several points on the process of entering the code for the certificate and how it can be done in a variety of ways. I would focus on those specific potential points of exploitation and ask about them specifically. – 0xSheepdog May 16 '17 at 18:50
  • @0xSheepdog Have you read the entire question? The title was already long enough so I've not put every single detail in it, but the question is (as said above) **How safe are those prompts from keylogging or other password interception techniques?** I'm not a native english speaker but I think it's pretty obvious that I'm asking what are the risks of having the password intercepted (by a rogue program - if there was that doubt I'm not particularly concerned about physical attacks). I wasn't asking for a numeric grade, of course. – gbr May 17 '17 at 11:43
  • @0xSheepdog Of course you need to know the environment to answer that question, as I said assume a Windows 10 reasonably hardened; it's not very specific, I know; if that was the problem I edited the question to assume a pretty much default new Windows installation for the time being, as right now I don't know what specific actions will be put in place and I'm relying in part on the outcome of this question to decide them (see the edit). – gbr May 17 '17 at 11:44
  • @0xSheepdog "_Makes about as much sense as the question_" Much more than your comment, to my eyes | "_You have laid out several points on the process of entering the code for the certificate and how it can be done in a variety of ways_" I have no idea what the fuck you're talking about. Yes I said fuck, sorry but I had very different expectations for this question; I took a considerable amount of time to write and research it and I expected to find a very different situation on this page after 15 hours. – gbr May 17 '17 at 11:44

2 Answers2

0

If a key logger is infecting your machine, any text you type, including the private key you enter to the SafeNet prompt will be stolen as you type it in. You better use an automated entrance of the private key like in this article I wrote. The idea is to use an API call to connect to the hardware token and to sign an .exe with it but instead of using the user interface provided by SafeNet.

Michael Haephrati
  • 172
  • 11
0

If we assume "reasonably hardened" include the "usual":

  1. An AntiVirus software that is NOT pirated. I am in no way recommending using pirated software, but, if someone is going to do it anyway, then they, at least, shouldn't use pirated AV. The AV is supposed to protect you from everything else... unless it is the threat itself, in which case game over.

  2. Regular malware scans, updated drivers, updated definitions

  3. Virtualisation-Based Security

  4. There are no privilege-escalation exploits, unhandled buffer overflows, data execution.

etc. etc.

There are 2 types of keyloggers. 1)

Hardware keyloggers are basically undetectable and usually pretty effective (unless some enterprise encrypted keyboard is used, that encrypts the bus data between the keyboard and the rest of the computer). Hardware keyloggers aren't usually a concern. If someone manages to install such a device, they could probably also install a camera, or beat you up. To stay undetected, there are very high operational costs to recover the data from the keylogger. Basically, these are Nation-State Level Attacks and if you suspect as such, you are in other kinds of dangers.

Software keyloggers, on the other hand, are much more common, easily deployed. The keyboard input for the 5110 is handled by the kernel keyboard driver and then passed to the safenet software, which basically uses a wrapper over the pkcs11 module to provide the minidriver and KSP on windows. The communication of the password to the token is done with Secure Messaging. The only weak point is the password prompt.

For the assumptions presented above about the "hardened" OS, it would take some pretty sophisticated keylogger to capture the password. It must be a kernel level driver and must also be signed by Microsoft, and the whole thing runs in a separate container because of the Virtualization Based Security. When using an EV Code Signing certificate, you should be careful with your machine and probably do the signing on a different computer than the one used for testing code etc.

From the above, it seems reasonably hard for a keylogger to just intercept your input. What, though, is more plausible is a fake password prompt where you are tricked type your password, it is intercepted and then the obvious follows. The fake-password prompt issue can be prevented by using your antimalware software, not installing untrusted software, being careful, and, very importantly, do not just give Admin privileges to any application that does not need it. Moreover, there is the so-called Secure Attention Sequence/Key, which basically suspends any programs and presents a secure prompt for you that runs in kernel level. Unfortunately, this would need further integration to somehow pass the password from the secure prompt to the Safenet prompt.

This might get some hate, but the whole point of having a hardware token is so that you don't have the credentials redily available. By having it plugged in constantly and using automation to sign, especially, if you are not using an AIRGAPPED dedicated machine, well... it defeats the purpose. People are usually concerned about their keys getting stolen. But, I put forward that it makes little difference if someone steal your keys and if someone doesn't steal them but can use them whenever he likes.

In the end, a regular software keylogger will not easily intercept your password either through the safenet prompt (unless it's fake and you are phished) or through automation solutions.

As for the automation solutions, I would say that they are bad practice, unless you have a dedicated machine just for signing, that is airgapped (good luck timestamping?), since they have constant access to the token activation data (password) and the token. How would that password be protected from threats other than keyloggers? All in all, it's a risk/reward scenario. They make people use hardware tokens for EV Code Signing certificates so that some risks can be mitigated, since at least the key material is controlled.

If you have such a high signing workload that would warrant automation, then it would probably be worth it to have a cheap machine dedicated to signing. If your workload permits manual signing, then just typing your password in the prompt is the best choice (and probably cheapest?), provided you are careful not to use a fake prompt and that you disconnect the token when you are done.

As a side note, I would like to comment on a reference about single log-on. Single-logon is for the "user certificates". The common criteria certificates can be made so that a secondary password is always requested.

ARGYROU MINAS
  • 111
  • 1
  • 10