3
$\begingroup$

In particular, in PKCS #11. Not a lot of information on the web; I found this explanations. Ignoring the empty marketing talk like “heightened security” and “centralized and secure management”, I managed to extract the following benefits:

  • secrets do not leave the token,
  • tamper-resistant audit of the usage of secrets.

In practice, “secrets do not leave the token” is not benefitial. In order to use a secret, a user needs to upload that secret to a program with a user interface (UI). For example, a banking application. This program is not able to execute on a token since tokens have insufficient UI. Hence this program will execute on a UI device to which the token is attached.

  • Suppose that the UI device is breached.

      1. If cryptographic algorithms are implemented in the token, the attacker can execute any operation that the user can as long as the token is attached.
      1. If cryptographic algorithms are implemented in the UI device, the attacker posesses the user's secrets.

    In practice, option 0 is as bad as option 1. For example, for a banking application, the attacker can sign a payment in either case.

  • Suppose that the UI device is not breached. Then we have equal security independently of where cryptographic algorithms are implemented.

Implementing cryptographic algorithms in the token has disadvantages:

  • AFAIK, PKCS #11 does not allow backups. If you store all your secrets in a token, it will be valuable not only to attackers, but to you too.
  • Restricted set of cryptographic algorithms. Only algorithms implemented in a token.
  • More complex hardware interface and API. [Update 2021-02-15. Here I am comparing to USB mass storage. If a token does not implement cryptographic algorithms, it is essentially an information storage device.]

Am I right?

$\endgroup$
1
  • 1
    $\begingroup$ You may want to note that there are also dedicated trusted hardware UI devices for smartcards and HSMs have those built-in. These tend to at least allow trusted PIN input and potentially have a trusted display (though using that is sadly out-of-scope for PKCS#11 even though it could be highly useful to e.g. display a hash before a signing operation). $\endgroup$
    – SEJPM
    Feb 3, 2021 at 9:22

3 Answers 3

6
$\begingroup$

In practice, “secrets do not leave the token” is not beneficial.

Ouch, I think I would rather like to know where my keys are. This is about the same as saying that you don't care if your house keys got copied or not.

For example, a banking application. This program is not able to execute on a token since tokens have insufficient UI. Hence this program will execute on a UI device to which the token is attached.

In PKCS#11 you can still have key specific PIN or passwords. This is especially important for transactions which is what you are referring to here.

Sometimes additional security measures such as counters are also present. If those are not depleted they can at least be used to check if the key was used unexpectedly. In software the attacker could just reset the counter at will. Cars also have odometer's that are deliberately hard to compromise.

That all said, yes, if an attacker has full access to the keys within the token over extended periods of time then the token is virtually useless.

If cryptographic algorithms are implemented in the token, the attacker can execute any operation that the user can as long as the token is attached.

Absolutely, and there is a balance between usability and security here, which is hard to maintain. E.g. you can setup a HSM in such a way that a person has to login into each session. Then again, you might have some trouble finding a human in the middle of the night that is able to do this upon a sudden restart of a server. This would be fine for personal tokens and smart cards.

Login procedures can also be protected by additional counter measures such as number of logins or delays between password verification checks.

If cryptographic algorithms are implemented in the UI device, the attacker posesses the user's secrets.

There are things like white box cryptography of course. And then there are certainly levels of access. Even in software you can have a secure system run at a different level than the user process. However, in that case you cannot easily protect against side channel attacks on processor usage. So this actually advocates for a hardware device such as a token.

AFAIK, PKCS #11 does not allow backups. If you store all your secrets in a token, it will be valuable not only to attackers, but to you too.

PKCS#11 is a generic token interface. However, most if not all HSM's have proprietary backup mechanisms and / or extensions of the PKCS#11 interface to deal with backups.

Other tokens such as smart cards basically require you to request a new smart card or token - which is fine for signature generation (authentication, non-repudiation). It is bit more tricky when it comes to decryption for obvious reasons.

Restricted set of cryptographic algorithms. Only algorithms implemented in a token.

Absolutely, and this can be a nuisance. And if you enable FIPS mode then only FIPS algorithms will be available. HSM's can receive (signed) updates though. And generally we don't use tokens for research, we tend to use them for standardized algorithms.

Some HSM's actually allow you to run restricted programs as well - although this may have interesting effects on certification of the hardware.

More complex hardware interface and API.

That's debatable. I think the PKCS#11 interface is well specified and it is about the only standardized, generic crypto API out there. It may not suite your language / runtime model perfectly, but the fact that you can use it from a myriad of languages and runtimes has a lot going for it. Many languages contain wrapper libraries around PKCS#11, which are then wrapped object oriented wrappers where required.

$\endgroup$
7
  • $\begingroup$ +1 for usage counters, my answer missed that! $\endgroup$
    – fgrieu
    Feb 3, 2021 at 9:39
  • $\begingroup$ +1 The first sentence almost knocked me out of my chair. $\endgroup$
    – Patriot
    Feb 3, 2021 at 14:59
  • $\begingroup$ “delays between password verification checks” Yes, this is useful for restricting the number of transactions. $\endgroup$
    – beroal
    Feb 14, 2021 at 22:11
  • $\begingroup$ “So this actually advocates for a hardware device such as a token.” Rather, it advocates for isolating processors in the UI device. $\endgroup$
    – beroal
    Feb 14, 2021 at 22:12
  • $\begingroup$ “More complex hardware interface and API. That's debatable.” I am comparing PKCS#11 to USB mass storage here. $\endgroup$
    – beroal
    Feb 14, 2021 at 22:12
5
$\begingroup$

At least one benefit of tokens is that even if the token is temporarily abused because "the UI device is breached", the key itself does not leak. Therefore, in some applications like server authentication, it's enough to restore the integrity of the breached machine to be back and running without changing the key. That capability is necessary in some fields: changing all customer smart cards is prohibitively expensive and distrupting in banking, pay-TV, fare collection, access control.

Using a security token protects against employees making an unauthorized copy of a key and using it off-site, perhaps later.

Another benefit is that it's possible to audit the token to try to ascertain the key can't leak, when that's futile for software implementations running on a PC: it seems all except the most simple CPUs fail at process isolation; and essential, simple, open-source security software such as sudo can have devastating security bugs that remain undetected for years.

Addition: as pointed by that other answer, some tokens have key usage counters, allowing audit to detect unauthorized usage; and the mere possibility of audit can deter unauthorized usage by insiders. In some applications, more elaborate audits are possible (e.g. adding the amount of financial transactions signed). This out of PKCS#11 scope, though.

There are working backup strategies for some security tokens, including PKCS#11, but out of the scope of that standard. In particular, there are HSM architectures where multiple physical HSMs are enrolled in the same PKCS#11 system, which becomes resistant to failure of any particular physical HSM, and scalable. The keys are essentially stored as an encrypted file that is exploitable by any HSM enrolled in the PKCS#11 system. Enrolling extra or replacement HSMs is possible only with the higher-level administration keys, not needed in daily use.

Note: Many tokens are protected when stored inactive, with a PIN. This is impossible with software only, where the best we can do is protection by a passphrase, which must be high-entropy, because software alone can't count PIN presentation errors. But as noted in comment, this is possible with a token regardless of the token itself doing the crypto or not. Thus this does not count as an advantage of doing the crypto in the token.

$\endgroup$
1
  • 1
    $\begingroup$ “Many tokens are protected when stored inactive, with a PIN.” You can do this without performing cryptographic operations in a token. I am not comparing “with token” and “without token”, I am comparing “token doing cryptographic operations” and “token not doing cryptographic operations”. $\endgroup$
    – beroal
    Feb 15, 2021 at 15:18
3
$\begingroup$

In practice, “secrets do not leave the token” is not benefitial. In order to use a secret, a user needs to upload that secret to a program with a user interface (UI).

What actually happens is that PKCS#11 provides a way for the UI to send data to the token to be signed using a private key or encrypted using a secret key. The token itself has the ability to compute signatures of data and to encrypt data, eliminating the need for the secret to leave the token.

PKCS#11 can require a "PIN" value (often a cryptographic key derived from a password) for any operations to be performed. An attacker gaining only the token and not the PIN cannot use the token to do anything.

There's also rarely any need for backups of token values. Instead one creates secrets outside the token, and stores the same secret values on multiple tokens, and then deletes the secret from the outside generation source. In some cases it is possible to back up secrets to be restored onto another token, by using some sort of "key wrapping" mechanism. EG the YubiHSM 2 hardware security module allows for "M of N" wrapping, where some number M out of N total keys are required to import and unwrap a backed-up key. "For example in an enterprise, the Active Directory root CA private key might be key wrapped for 7 administrators (M=7) and at least 4 of them (N=4) are required to import and unwrap (decrypt) the key in the new HSM."

Your last two points are correct, however. The set of cryptographic algorithms is more restricted, and the hardware interface and API are more complex to use. The former isn't necessarily a disadvantage, since the restricted set of algorithms can prevent insecure choices by users.

$\endgroup$
1
  • $\begingroup$ “In practice, “secrets do not leave the token” is not benefitial. In order to use a secret, a user needs to upload that secret to a program with a user interface (UI). What actually happens is that PKCS#11 provides a way for the UI to send data to the token to be signed using a private key or encrypted using a secret key.” You are right, I expressed myself poorly. Secrets are useless without UI. $\endgroup$
    – beroal
    Feb 15, 2021 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.