Key role is a term defined in [11] that specifies in which roles the key is intended to act over time. For example, shortly after its generation, keyK
may have no role available at all, but then k may be enabled for the role to be extracted and exported to other domains, and after transport to another domainK’s roles may be modified again, to disable the previous role and to enable the rolesfor data encryptionandfor data decryption.
From the point of view of this thesisKey roleis defined by the attributes of the cryptographic key. If an implementation enforces key roles, such as proposed in [5], there are the following questions to consider:
1. Does akey rolehave to be defined on key creation? 2. Can a cryptographic key have more than onekey role? 3. Is it possible to changekey roleof a key?
4. Can the token know the right role to use for a key?
5. Does the design break if the communicating tokens don’t agree on a role?
In order to answer the above questions it is first necessary to define the basic proposed roles relevant to the cryptographic key storage.
∙ Wrapping Key - key with this role only has the attributes WRAP,
UNWRAP,SENSITIVEandEXTRACTABLEset totrueand all other
attributes arefalse.
∙ Encrypting Key- this key hasENCRYPT,DECRYPT,SENSITIVEand
EXTRACTABLEset totrue, all other attributes arefalse.
∙ Imported Key - this key has ENCRYPT, UNWRAP, SENSITIVE and
DERIVEset totrue, all other attributes arefalse.
The proposed key roles are based off [5]. They should allow for asym- metric usage of keys. For example a key Kis generated on one deviceD1
with role Encrypting Key. It is then exported via WrapKey and later im- ported onto another deviceD2viaUnwrapKey. On the deviceD2the keyK
is automatically assigned the roleImported Key. Now both devices have key
K, butencrypt ->decrypt process can only be performed inD2-> D1direc- tion, because on device D2keyKbelongs to role Imported Key, which can- not useDecrypt. Therefore it is necessary to establish another key (or key pair) between the two devices which will permit encrypted communication in the opposite direction. While this approach doubles key management, it eliminates the possibility ofExpanded Key Separation Attack,Downgrade At- tackand both attacks that result in atrojan key. Note that the samerolesalso apply to the asymmetric cryptography, although they are less intuitive.
The above example answers question one (Does akey rolehave to be de- fined on key creation?) with the case of an imported key. Since the tokens may be stateless, importing a new key without immediately defining its role can be very dangerous. Imagine a situation when a key is imported and its role is left empty at first, but later it is assigned the roleWrapping Key, be- cause the device was somehow made to forget the key was imported (e.g. through hardware tampering). Therefore it is necessary to always define role for each key immediately after it is created. There may be some excep- tions to this, such as when a key is generated on the token. Still, even in such a case there is no reason not to define the role right away.
Question two (Can a cryptographic key have more than onekey role?) is a matter of a trade-off. Allowing more than one role with one key is possible (e.g.CKM_RSA_PKCSmechanism [16]) and permits using one key for mul- tiple cryptographic operations. It clearly should never be possible for a key to have bothWrapping KeyandEncrypting Keyroles, but combining one of these with e.g.Signing Keymay reduce cryptographic key overhead signif- icantly. However, even such combination may lead to dangerous misuses. Therefore it is not recommended to give multiple roles to one key, even if they are not conflicting. In any case every key should only be able to have at most onekey rolerelated to cryptographic key storage.
And should it be possible to changekey roleof a key? The are three basic approaches to this problem. First is to make thekey roleschangeable without any limits. This approach obviously fails, since it would be possible to just change a key from Wrapping Keyto Encrypting Key, so that it can decrypt. Thekey rolemechanics would make no sense, since it would no longer pre- vent even theKey Separation Attack. Second approach would be to makekey rolessticky in the similar manner asSENSITIVEattribute. Clear downside to this approach is that it makes the cryptographic keys rigid and increases key overhead. Third approach is to permit only some key role alteration, e.g. it would be possible to removeSigning Keyrole, but notWrapping Key. Similar to proposed solution to question #2, this approach could reduce key overhead.
While some roles are defined merely by the process of creating the key (e.g. key imported viaUnwrapKeymust always have the roleImported Key. On the other hand, keys created via GenerateKey should let the user choose if the key will have the roleWrapping Key,Encrypting Keyor neither. Therefore in some situations the token can immediately know the correct rolefor the key, but at other times the user must decide.
Answer to the last question clarifies that even with the proposed re- strictions the PKCS#11 tokens still can be vulnerable to some of the attacks shown in this thesis as long as not all the implementations conform to the standard. Consider a simple example whereD1is a device that correctly im- plements the standard including therolemechanics, deviceD2that is a ma- licious or just erroneous device and does not implement therolemechanics and is vulnerable to the previously shownKey Separation Attackand asecret keyKwith the roleWrapping Keyshared betweenD1andD2. While the key
Kshould correctly have therole Imported KeyonD2, it does not and it even
hasDECRYPT=true. That meansD1assumes it can safely wrap itsEncryp-
tion Keyand send it toD2, where it should be unwrapped asImported Key. However,D2instead uses itsKto decrypt the wrapped key rather than to
unwrap it, which compromises the whole scheme. Therefore this approach could only be considered secure if all implementations conformed to the standard, including therolerestrictions.
Unfortunately, the less restrictive approaches tokey rolesalso seem prone to implementation errors. While they may work in theory, it has been shown [5] that many PKCS#11 implementations are vulnerable to very simple at- tacks because of incorrect implementation of the standard. Therefore the most restrictive approaches to the above problems should be adopted.
The result of such approach would be that essentially every crypto- graphic key would have to be used asymmetrically as shown above. More- over, there would have to be a different key for every cryptographic op- eration. It may seem very restrictive from theoretical point of view, but in practice, many cryptographic keys are single-purpose anyway. Therefore the best case scenario is that one cryptographic key still suffices (this may apply in e.g. signing documents or emails). Worst case scenario would in- crease key overhead so that instead of just one key the user would need to use six or even more keys, but such a situation is not very likely to occur in practice. Moreover, one of the goals of the PKCS#11 standard is that the stored cryptographic keys are secure.
Unfortunately some widely used protocols may encounter problems with this approach. Consider the example of The Transport Layer Secu- rity (TLS) Handshake Protocol [10]. This protocol does not use WrapKey
orUnwrapKey(although in some cases it may actually use them to create
themaster secret) and instead utilizes DeriveKey to achieve shared keys. Since any key obtained viaDeriveKeywould be consideredImported Key, the shared keys could only encrypt, but not decrypt. This means that the role mechanicswould not work in every situation.