Destroying a persistent key open through multiple handles does not invalidate other handles #214

New issue

Open

opened 2019-08-13 08:00:05 -05:00 by gilles-peskine-arm · 1 comment

gilles-peskine-arm commented

2019-08-13 08:00:05 -05:00

(Migrated from github.com)

Description

Consider the following sequence of operations (assume nothing fails):

psa_set_key_id(attributes, 3);
psa_open_key(attributes, &handle1);
psa_open_key(attributes, &handle2);
psa_destroy_key(handle1);
…
psa_xxx_setup(…, handle2, …); // Using a destroyed key!
…
psa_set_key_id(attributes, 3);
psa_generate_key(attributes, &handle3);
…
psa_destroy_key(handle2); // Destroying a different key!

Initially, there is a key with the identifier 3, and we take two handles to the same key. The first call to psa_destroy_key wipes the key slot for handle1 and wipes the key in storage, but does not invalidate the key slot for handle2. This results in several undesirable behaviors.

If the key is transparent (i.e. not in a secure element), it is still possible to use the key via handle2, because Mbed Crypto maintains an independent copy of the key in each slot. This means that psa_destroy_key failed to deliver its promise of wiping the key material, making the key unusable.
If the key is in a secure element, it is still possible to attempt to use the key via handle2. But the key has been wiped from the secure element, so attempting to use it will either fail or trigger an operation with some other key (which may even be of a different type, leading to interesting cryptographic information leaks) depending on whether the slot number in the secure element has been reused.
If the key identifier is reused before calling psa_destroy_key on handle2, this destroys a key in storage which is not the key that handle2 references.

This is somewhat related to #86 which is about multipart operations retaining key material of a destroyed key.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

### Description Consider the following sequence of operations (assume nothing fails): ``` psa_set_key_id(attributes, 3); psa_open_key(attributes, &handle1); psa_open_key(attributes, &handle2); psa_destroy_key(handle1); … psa_xxx_setup(…, handle2, …); // Using a destroyed key! … psa_set_key_id(attributes, 3); psa_generate_key(attributes, &handle3); … psa_destroy_key(handle2); // Destroying a different key! ``` Initially, there is a key with the identifier 3, and we take two handles to the same key. The first call to `psa_destroy_key` wipes the key slot for `handle1` and wipes the key in storage, but does not invalidate the key slot for `handle2`. This results in several undesirable behaviors. 1. If the key is transparent (i.e. not in a secure element), it is still possible to use the key via `handle2`, because Mbed Crypto maintains an independent copy of the key in each slot. This means that `psa_destroy_key` failed to deliver its promise of wiping the key material, making the key unusable. 2. If the key is in a secure element, it is still possible to attempt to use the key via `handle2`. But the key has been wiped from the secure element, so attempting to use it will either fail or trigger an operation with some other key (which may even be of a different type, leading to interesting cryptographic information leaks) depending on whether the slot number in the secure element has been reused. 3. If the key identifier is reused before calling `psa_destroy_key` on `handle2`, this destroys a key in storage which is not the key that `handle2` references. This is somewhat related to #86 which is about multipart operations retaining key material of a destroyed key. ### Issue request type [ ] Question [ ] Enhancement [x] Bug

ciarmcom commented

2019-08-13 11:05:20 -05:00

(Migrated from github.com)