Extend external storage API to allow cryptographic operations

[jannef]

The documentation states:

Protecting against inspection of the Nuts node process.
        If an attacker can inspect the memory of the Nuts node process, confidentiality might be private keys lost.
        Why don’t we protect against it: same reasons as for an attacker with root access.

There however is no need to store confidential keys in nuts process. Even many cloud-based secret storage solutions such as Azure Key Vault supports cryptographically signing via an API. This way the key never leaves the secret storage, and is never exposed. This would allow use of HSM (Hardware Security Module) backed keys, which our organisation would prefer.

To achieve this, two new endpoints are required: one to generate a HMS backed key; and another to sign with pre-existing key.

[reinkrul]

We considered this, as it's obviously safer. I think we chose the read-then-use approach instead, because we wanted to use NIST P256 Elliptic Curve keys for encryption (through ECDH), which wasn't supported by the commonly available (software) HSMs at that time. But, encryption isn't required in v6, so this could be reconsidered.

Note: does the KIK-v use case encryption through the Nuts node? I know we have the encrypt_jwe and decrypt_jwe operations. (maybe @hietkamp knows)

[hietkamp]

My answer would be a guess, I didn't implement the software. @bdalenoord should know.

[reinkrul]

@hietkamp do you know whether RSA or EC keys are used? (for RSA the node uses RSA-OAEP-256, for EC ECDH-ES+A256KW).

[woutslakhorst]

The current implementation is a MVP that also supports encryption and decryption using asymmetric keys Having an API that does not expose the keys would be ideal, but most (last time I checked) crypto backends only support signing and not encryption. That would mean we have to support different types of backends. It's a good step but currently outside our budget.

[bdalenoord]

To answer @hietkamp 's question: I'm not aware of KIK-V using encryption.

The KIK-V bolt states the following:

Uitgangspunt voor KIK-V is dat de antwoorden op gevalideerde vragen geen persoonsgegevens bevatten. Daarom wordt vooralsnog geen berichtversleuteling toegepast. De didcomm-specificatie staat toe dat versleuteling kan worden toegepast. In de toekomst kan daarom op enig moment alsnog besloten worden tot versleuteling.

(from https://kik-v-publicatieplatform.nl/documentatie/nuts-bolt/1.0.0-RC5/Documentatie/Aanvullende%20specificaties#6.5.-berichtversleuteling)

Which roughly translates to (AFAIK): we don't use encryption yet, but may choose to do so in the future.

[jannef]

We considered this, as it's obviously safer. I think we chose the read-then-use approach instead, because we wanted to use NIST P256 Elliptic Curve keys for encryption (through ECDH), which wasn't supported by the commonly available (software) HSMs at that time. But, encryption isn't required in v6, so this could be reconsidered.

I'm not really an export various products available in the market, but at least Azure Key Vault supports (with hardware HMS backing):

• NIST P-256
• SECP256K1
• NIST P-384
• NIST P-512

API that does not expose the keys would be ideal, but most (last time I checked) crypto backends only support signing and not encryption.

Encrypt and Decrypt operations are also available.

That would mean we have to support different types of backends.

The external API already abstracts the actual implementation. It should not be too bad to publish v2 API definitions, and create another implementation in nuts node. It should be simple as just injecting a different version the encryption abstraction (with ioc).

Since these features are available in the public cloud for relatively low price, it would make sense to support them and leave the legacy option open for organisations whose infrastructure does not support latest security features.

[woutslakhorst]

Note: Hashicorp Vault is one of the backends we support and as far as I can tell it doesn't allow for decryption when encrypted outside of vault. It seems to be designed with encryption and decryption done by the same vault instance in mind.

I think we all agree on moving signing and decryption to the backends, but if we do that now, it might break the feature for some of the backends.

[reinkrul]

We now support Azure Key Vault (at least for v6 use cases).