Externalise keys storage

[jakipatryk]

Background

Currently the only signing key for JWTs is generated & stored in memory. So when there are multiple instances of login-gateway deployed under a load balancer, as each instance will have different key, it is impossible to use the service.

Feature

Fetch key(s) for signing JWTs from external service (pref some AWS service).

[dk1844]

AWS Secrets Manager comes to mind at first.
There, we should be able to create a Lambda fn for key rotation, too. (#47).

Alternatively, in theory, KMS could be used, but this would cut deep into the logic of the service, because in that case, we would not have access to the private key at all - all verification would have to be externalized to KMS.

[kevinwallimann]

Storing keys in memory is also a potential security threat. While I was asking chatGPT to write code to generate keys in memory (please don't look at the ingestionaas repo about what we're currently doing), it gave the following warning:

While it may seem that storing keys in memory (RAM) would be secure, given that they're not written to disk and therefore not vulnerable to issues like data remanence, there are several reasons why it's not generally considered secure:

1. Memory dumps: If an attacker can gain access to a system, they may be able to force a memory dump or read the memory directly, thereby accessing the keys. This could happen via a process crash or debugging tools. Some malicious software is even specifically designed to scan memory for sensitive data such as cryptographic keys.

2. Cold Boot Attacks: In a cold boot attack, an attacker with physical access to a machine can reboot the system and then dump the contents of memory before they're erased. Research has shown that data can persist in memory for several minutes or even longer after power is removed, especially if the memory chips are kept cool.

3. Swapping and paging: Operating systems often move data from RAM to disk as part of their memory management processes (this is known as swapping or paging). If keys are stored in memory, they could inadvertently be written to disk as part of this process.

4. Side-Channel Attacks: Sophisticated attackers might use side-channel attacks to derive the keys. These types of attacks involve using information like the time it takes to perform an operation or power consumption to infer what data is being processed.

5. Software Vulnerabilities: If a software vulnerability exists, such as a buffer overflow, an attacker may gain access to different parts of the memory, potentially gaining access to your keys.

Because of these and other risks, sensitive information like cryptographic keys are often stored using secure key storage mechanisms, which could involve dedicated and protected hardware (HSM), or software that encrypts keys when they're not being used. When keys are in use, measures are taken to limit the amount of time they're in a decryptable state in memory, and to ensure they're erased as soon as possible.