Recently, I have been working on a new evening/weekend project that I would like to share as it might be useful to others as well.
distributeyacts as intermediary between a key consumer and a key service. It receives requests from the key consumer, fetches the key material from the key service and sends back JWE-wrapped (RFC7516) responses.
distributey (say “duh·stri·byoot·i”) exist? Particularly in enterprises, key material is often generated on-premises for compliance & security reasons. Traditionally, HSMs are often used to create and store said key material. However, using the cloud becomes increasingly popular which inevitably leads to the challenge that the on-prem key material must be made available to cloud encryption services. Typically, one of two approaches is used to distribute key material in such a situation: bring your own key (BYOK) or hold your own key (HYOK). BYOK means that the key service actively pushes key material to a key consumer (“the cloud”) while HYOK means that the key consumer can request key material from the key service. The rationale behind HYOK is that the key consumer holds the key material in a temporary cache that is flushed frequently. If a specific key is required, it is requested on-demand. Many popular key services do not support HYOK out of the box, which is where
distributey comes into play. It can be installed “in front of” a key service, serving HYOK requests from key consumers by communicating with the key service on their behalf.
This is the process, triggered by the key consumer, to distribute key material:
- The key consumer requests key material by issuing an HTTP GET request to
distributey. Its request contains the key identifier (
kid) and a
nonceto prevent replay attacks.
distributeyretrieves the key material identified by the
kidfrom the key service.
- The key consumer unwraps the key material in the
JWEtoken and imports it.
The tech stack used to implement
distributey is rather simple:
Learn more about