Right now the derive_key mechanism implemented in #10 only allows deriving a secret 256 bit keys. It might be interesting to make the type of the key configurable.
The current implementation is already not that practical. In Opcard, the admin PIN can be used to change the GPG key, which can then be only used after verification of the user pin.
This means that the admin pin need to somehow be capable of encrypting the GPG key as if it had the user's pin. To do that, the opcard implementation wraps the user pin key using the admin pin key.
This works, but is not viable for PIV, or with secure messaging. In those context, no "admin pin" is used, and authentication happens through an AES encryption or challenge-response. This means that there is no way to derive entropy from the admin authentication which can be used to wrap the user pin key.
The solution I propose would be to allow other mechanisms to be used to derive the key that is obtained by get_pin_key. The main goal would be to support either x25519 or P256 keys that can be used to asymmetrically encrypt data. That way an authenticated admin could still wrap the keys in a way that can only be read by the user.
Right now the
derive_keymechanism implemented in #10 only allows deriving a secret 256 bit keys. It might be interesting to make the type of the key configurable.The current implementation is already not that practical. In Opcard, the admin PIN can be used to change the GPG key, which can then be only used after verification of the user pin.
This means that the admin pin need to somehow be capable of encrypting the GPG key as if it had the user's pin. To do that, the opcard implementation wraps the user pin key using the admin pin key.
This works, but is not viable for PIV, or with secure messaging. In those context, no "admin pin" is used, and authentication happens through an AES encryption or challenge-response. This means that there is no way to derive entropy from the admin authentication which can be used to wrap the user pin key.
The solution I propose would be to allow other mechanisms to be used to derive the key that is obtained by
get_pin_key. The main goal would be to support either x25519 or P256 keys that can be used to asymmetrically encrypt data. That way an authenticated admin could still wrap the keys in a way that can only be read by the user.