What is the purpose of implementing cryptographic algorithms in a token?

Question

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.

  • 0. 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?

Answer 1

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.

Answer 2

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.}

Answer 3

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.