Cryptographic Key Management: How To Secure Implantable Medical Devices

This article provides guidance on where to start and primary considerations when designing your cryptographic key management system for an implantable medical device. Keep in mind that the scope of this article will be focused on the implant itself, so that we will discuss microcontroller (MCU) and firmware flavors of key management rather than mobile or cloud-flavored key management.

---

Introduction

The Internet of Things (IoT) is taking over the world. Microwaves, lightbulbs, vacuum cleaners, and pretty much any everyday object with the word “smart” in front of it; all want to be wirelessly connected, whether it be through Wi-Fi or Bluetooth. Many of these innocuous devices are developed and produced with tight budgets, and unfortunately, one of the easiest things to cut out of a development budget is security infrastructure.

There are quite a few articles out there that demonstrate just how easy it is to gain access to some of these smart devices. For example, in “Reverse Engineering of a Not-so-Secure IoT Device,” they break down a mysterious monitoring device that commits quite a few security sins — like transmitting a plaintext encryption key over serial lines.

While the consequences of using these poorly secured IoT home devices can range from minimal to  somewhat concerning — depending on the types of devices and the data they transmit — it is a very different story when it comes to connected medical devices in the Internet of Medical Things (IoMT).

The Need for Security in Implants

Imagine an IoMT device without security, personal medical data being spewed out over the 2.4 GHz spectrum for anyone to receive, or an implanted medical device giving complete control to any Bluetooth device that decided to connect. This situation is not just horrifying; it’s a matter of life and death.

In implantable medical devices, there’s zero room for error — security isn’t optional, it’s essential. Unlike other products that can be returned if compromised, an implant can’t be easily removed without risking severe, irreversible harm to the patient. On top of that, failing to comply with critical regulations like HIPAA could result in severe penalties.

So, how do we bridge the gap between the dire need for security in implantable medical devices and the technical solutions available? The answer lies in effective cryptographic key management. It’s not just about choosing the right algorithms. It’s about how you manage, store, and rotate these cryptographic keys that make or break the security infrastructure.

A vast suite of cryptographic algorithms are available for authentication and confidentiality, and at the heart of many of them are cryptographic keys.

---

What are Cryptographic Keys?

What exactly is a cryptographic key? Simply put, it’s a string of random data. This string is used to change readable data (plaintext) into a secret code (encrypted data). And it works the other way around, too. A key could be as basic as the word “hello” or as complex as a long string of characters and symbols. For example “YZICgJjXhZ7gHw1s8n5JKmaedpnWVucC/yqeNGHpcXy83cN/dR”. 

Think of it like a house key. Just as a physical key locks and unlocks your home, a cryptographic key encrypts and decrypts data. Only those with the correct key can access the information. But here’s the catch — what if you leave your house key under the doormat? It’s the same with data. You’re asking for trouble if you send the cryptographic key along with the encrypted data.

Cryptographic Key Management is crucial when designing the security for an implantable medical device. It involves four main areas: the types of keys, how they’re created (key generation), where they’re stored (key storage), and how they’re used (key usage).

---

Types of Cryptographic Keys

There are two kinds of cryptographic keys: symmetric and asymmetric.

Symmetric Keys

Symmetric keys are relatively straightforward. A key is used to encrypt a message, and that same key is used to decrypt the message. It is easy to grasp as a concept, but it can lead to some tricky challenges. 

Because one key is used for encryption and decryption, whoever needs to decrypt the message must have the same key. So, some secure transport method is necessary to get the key to the required parties. On top of that, instead of worrying about just storing one key securely (whoever is encrypting it), you need to worry about securely keeping keys on all the desired recipients.

Despite these shortcomings, symmetric key encryption has some key advantages worth considering. Symmetric key encryption tends to be much faster and less resource-intensive than asymmetric key encryption. These advantages go far in a resource and power-constrained environment such as a battery-powered implant. 

Symmetric keys are also the primary output of common key exchange/agreement algorithms, allowing session keys to be designed into the security architecture. Session keys are ephemeral, meaning they have a shelf life or expiration. The shelf life of a session key is flexible and can be almost anything. 

For example, the key could be single use, or it could last the length of a BLE connection, or it could have a set amount of encryption uses before it expires. The important thing is that session keys help limit the scope of damage that could be done if a particular session key is leaked. If one session key is leaked, it can only decrypt the messages sent within that session. This idea is called forward secrecy, meaning that any leaked session keys will not directly compromise the security of future session keys. 

Asymmetric Keys

Asymmetric keys — also called asymmetric keypairs — have two parts: a public key and a private key. Their names hint at how they should be handled; a public key can be passed around to anyone and everyone, while the private key should be kept hidden. No one should have the private key outside of the owner. Algorithms that use asymmetric keys are also called public key algorithms.

With public key algorithms, encryption is done with the public key, while the private key is used for decryption. This approach allows anyone with the public key to send encrypted messages, but only the private key owner can decrypt the message.

Asymmetric keys are also commonly used to create digital signatures. A private key can generate a unique signature over a piece of data, while the corresponding public key can verify the signature. Digital signatures do not provide any form of encryption or confidentiality, but they can provide forms of authentication and integrity of the data. Successfully verifying the signature proves that whoever sent the message has the private key (authenticity) and that the message was not tampered with (integrity), as the signature is unique to the message sent.

What Keys Should We Use?

This is a trick question! Use both!

For the use case of streaming data from an implant to an external device, symmetric encryption is almost always going to be the ideal key type to use. The performance benefits are a must for the resource-constrained implant, the burden of having to establish the keys needed for communication is limited in a one-to-one scenario, and we maintain forward secrecy with proper session key expiration dates. Whenever possible, we should strive to use symmetric keys through the use of key agreement algorithms.

However, encryption is not the only concern in security architecture. What good is locking up the data with a key if we are willing to give it to anyone asking for it? We need authentication to ensure anything that attempts to interact with the implant is legit and isn’t just pretending to be a device the implant wants to talk to.

Authentication Through Digital Certificates

Authentication is where asymmetric keys shine. We can take an asymmetric keypair and create a digital certificate, essentially just a collection of information about the device that owns the asymmetric keypair. Including the device’s public key within the certificate allows other parties to validate any signature created by the private key.

The digital signature at the end of a certificate is generated using the private key owned by a Certificate Authority (CA). A CA is any entity or party that uses its private key to sign other entities’ certificates, allowing the CA to “vouch” for the certification it signs. The certificate’s signature enables any party to check the certificate’s authenticity by using the CA’s public key to verify the signature on the certificate. 

The definition of a CA is relatively minimal and can come in many different forms. Many web hosting companies offer CA services to issue website certificates (with the Internet Security Research Group (ISRG) offering a nonprofit CA solution). Amazon Web Services (AWS) provides a CA service to integrate certificates and certificate signing into your potential cloud solutions. A CA can also be a custom-made device to sign certificates for your system (although a higher level of care is needed for this option). 

In practice, there is rarely just one CA in charge of signing all certificates. If a CA’s private key were to be leaked, the authenticity of all certificates it had ever signed would be at risk. Commonly, there is a root certificate CA who can sign and vouch for many other intermediate CAs. Those intermediate CAs can then sign other intermediate certificates or an end-user certificate. This process creates a chain of trust that can be traced back to the root certificate. Having the intermediate CAs sign end-user certificates helps minimize the chances of leaking the root key and minimizing the scope of damage if an intermediate CA private key were leaked.

It can be a little much to wrap your head around, but this concept is the cornerstone of modern internet security. Have you ever been to a website whose URL starts with “http” and your browser gives you a scary warning? That is because the website did not provide the browser a certificate that can be traced back to a trusted and known root CA, meaning whatever website you are trying to access could be anything. It could be the website you want to access, or it could totally be lying. However, URLs with “https” are able to provide a certificate that traces back to a trusted CA. This ensures that the website you think you are talking to is actually the website you want to talk to. And it’s all based on asymmetric keys!

In Google Chrome, it is pretty easy to view the certificate of the website you are currently on. To the left of the address bar is a little lock icon. Click on it, then click on “Connection is secure” -> ”Certificate is valid”, and a window will pop up with information about the website’s certificate. If you do this on the Punch Through website, you can see its root CA comes from the ISRG!

---

Key Generation and Distribution

Entropy

The most important component in key generation is entropy. And no, we are not talking about thermodynamics and the heat death of the universe. Without getting into the nitty grittiness of it — and boy, can it get nitty gritty fast, check out the Wikipedia page for entropy — entropy in cryptography is a measurement of how random something is. We need good randomness for key generation so potential attackers can’t guess or figure out the key.

Because computers are deterministic and only perform what they’re programmed to execute, nothing they generate can be completely random. This reason is why an external entropy source is needed. A great example of lousy entropy can be witnessed in this 1996 article on “Randomness and the Netscape Browser.” It outlines how Netscape derived encryption keys using the time of day, the process ID, and the parent process ID. Those three metrics are not random and are easy to figure out retroactively. Alternatively, Cloudflare famously uses a wall of 100 lava lamps as a good entropy source for their key generation. 

Many microcontrollers will have hardware peripherals that are used to generate random numbers. There are two kinds of random generators: True Random Number Generators (TRNG) and Pseudo Random Number Generators (PRNG). Suppose you will use a hardware peripheral to generate these random numbers. In that case, you need to be careful that they are providing the appropriate level of randomness and understand the differences between the two types. 

Pseudo-Random Number Generators (PRNG)

PRNGs are algorithms used to obtain a random number based on an initial input. They are considered “psuedo random” because they technically aren’t random, they just generate sequences of numbers that look random based on the input to the algorithm. This input is often called a seed when using RNG speak. 

The most important step in using a PRNG for key generation is seed selection. If an attacker were to obtain the seed used in the PRNG, and the output of the PRNG is used as a key, then the attacker would be able to calculate that same key. Remember the Netscape fiasco from a few paragraphs ago? That vulnerability was centered around Netscape choosing easily obtainable sources of information as seed for their PRNG used for generating encryption keys. 

Luckily, PRNG has a special flavor, a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) — cryptography is not known for brevity. CSPRNGs are algorithms that are proven to be sufficiently random (they pass the next-bit test) and are hardened against cryptographic attacks. CSPRNGs also do not require the user to explicitly set the seed, as they are often designed with hardware that provides sources of sufficient entropy to derive seeds. Long story short, look for PRNGs that are called CSPRNGs or are specifically designed for cryptographic uses. The nRF52840 MCU from Nordic is a good example of language to look for when determining if a PRNG is appropriate for generating keys. Phrases like “suitable for cryptographic purposes,” “based on internal thermal noise,” and “does not require a seed value” are all great qualities to have!

True Random Number Generators (TRNG)

While PRNGs are just algorithms (and are ultimately deterministic), TRNGs rely on hardware to provide an external source of randomness occurring in the physical world that is inherently unpredictable. Some common sources would be thermal noise, atmospheric noise, or even the radioactive decay of isotopes. What do you think is easier to include on a microcontroller? Yeah we probably don’t want to rely on radioactive decay as our source of randomness. Thermal noise on the other hand is present within all electronic circuits and is an easily accessible source of randomness.

Many microcontrollers will offer both TRNGs and PRNGs, allowing the TRNG to generate a truly random seed for the PRNG. As mentioned above, this is exactly what the nRF52840 does with its RNG implementation.

National Cryptographic Specifications & Standards

It is also best not to trust an RNG peripheral because it has the word “random” in it. Look at documentation to see if it lists any reputable standards it complies with. For example, the National Institute of Standards and Technology (NIST) has many detailed cryptographic specifications and standards to adhere to. A good example is looking for RNG peripherals compliant with: 

• NIST 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators
• NIST 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation

Symmetric Keys

We discussed earlier how key distribution can be a tricky problem to solve with symmetric keys. If one party decides what key to use for encryption and decryption, how do we get it to the party who needs it? 

Diffie-Helman

The easiest way is to ensure one party is not in charge of generating the key and make it a joint venture. The Diffie-Hellman key exchange algorithm enables two parties to independently and concurrently derive a shared key. Both parties must generate an asymmetric keypair and send each other their public keys. Each party then combines its private key with the received public key, and then they will have a matching shared secret. 

However, the shared secret generated from a Diffie-Hellman exchange does not contain the proper amount of entropy — mainly that the shared secret’s randomness is not guaranteed to be uniformly distributed — to be used directly in encryption algorithms. The generated shared secret can then be fed into a key derivation function to get a symmetric key with the proper entropy. 

Key Derivation Functions

Key Derivation Functions (KDFs) are algorithms that transform some form of keying material — like a shared secret, password, or other keys — into one or more keys. They can strengthen weak input keys and produce output keys that are longer or different in form. So, in a Diffie-Hellman exchange, both parties can independently feed their shared secret into a KDF to generate a common encryption key.

Key Derivation Keys

Key Derivation Keys (KDKs) are keys used as input to KDFs. These KDKs can be temporary keys obtained from a key exchange — like our Diffie-Hellman example — or pre-shared static keys. A pre-shared static key is beneficial for secure serial communication between two processors on the same circuit board, like an application processor talking to a networking co-processor. The KDK can be generated and shared at the time of manufacturing. Then, upon bootup in the field, the two processors can exchange random numbers, feed the shared KDK and these random numbers into a KDF, and secure all subsequent communication.

Important Note: If a key is designated as a KDK, it must NEVER be used directly in an encryption operation. KDKs are not guaranteed sufficient entropy to be used safely for encryption. If a KDK is used this way and gets leaked, all past and future encryptions using that key could be compromised. Instead, use the KDK only for deriving session encryption keys. This decreases the KDK’s exposure to a potential attacker, ensures sufficient entropy for encryption keys, and provides forward secrecy if the derived session keys are leaked.

Asymmetric Keys

Figuring out how to securely get symmetric keys to the right parties is tricky. This is not so much a problem for asymmetric keys due to asymmetric keys being split into private and public keys. In almost all situations, asymmetric keys should be generated on the device. This ensures that the private key does not ever have to leave the device, and the public key can be sent around freely. 

Just as with symmetric keys, a random number generator with a sufficient entropy source must be used to generate asymmetric keys. If no RNG is available on the device, then one option is to generate the key from an external source and send it to the device through some secure channel or process during manufacturing. However, this is NOT recommended. The best way to keep private keys secure is not to need to transmit them. If your device does not have sufficient RNG to generate keys securely, it cannot be trusted to execute cryptographic algorithms. 

---

Key Storage

Arguably, the most critical aspect of cryptographic key management is storage. We know the keys and how to get them, now how do we store them?

Use A Hardware Secure Module (HSM)

A hardware secure module (HSM) refers to any hardware or co-processor dedicated to storing secrets and carrying out cryptographic operations. Examples include Apple’s Secure Enclave (built into all Apple custom silicon), Microsoft’s Trusted Platform Module (TPM), and Arm’s CryptoCell.

HSMs are designed to be tamper-resistant and are hardened against common hardware attacks like side-channel attacks and power glitching. On top of that, HSMs are isolated hardware components. This isolation complicates compromising keys through software-based attacks like a buffer overflow. HSMs also often can generate high-quality keys. If the HSM is also capable of storing these keys, then the key never really has to leave the HSM, heavily decreasing the risk of exposure.

Along with all the security advantages, HSMs contain hardware-accelerated implementations of standard cryptographic algorithms. These implementations free the application processor from performing potentially frequent and expensive crypto operations and reduce the power needed to carry out those operations.

Using an HSM is a no-brainer for implantable medical devices and should be prioritized when selecting a microcontroller. Hopefully, you are coming across this guide before the hardware designs are finalized! 

Common Microcontrollers With HSM

Nordic’s nRFX series

Nordic’s most popular line of BLE microcontrollers have cryptographic accelerators of various capabilities. 

• Nordic nRF52840 contains an Arm CryptoCell 310 for cryptographic hardware acceleration but does not have dedicated hardware secure storage for keys. 
• Nordic nRF5340 includes an Arm CryptoCell 312 for hardware acceleration and a dedicated key management unit (KMU). 
• Nordic nRF54 is their newest chip and has not yet been released, but they promise to provide more security than ever with their past microcontrollers. However, at the time of writing, no specific details about the nRF54s’ security capabilities are publicly available. 

ST Microcontrollers

ST has an enormous amount of microcontrollers available. It can be overwhelming to sift through. It can get even more confusing when considering security. 

• If you are set on utilizing an HSM included within an ST microcontroller, then your only option is the STM32WB series. They provide hardware secure storage through their customer key storage (CKS) peripherals. 
• If you are open to using an external HSM, ST’s ultra-low-power offerings may suit your implantable device. Some examples are the STM32L4, STM32L5, and STM32U5 series.

External HSM Solutions

Maybe you don’t have any flexibility in your microcontroller selection, which is okay too! Luckily there are dedicated Integrated Circuits (ICs) that you can interface with your microcontroller to gain the advantages of an HSM.

Microchip ATECC608

Microchip’s ATECC608 IC provides all the goodies of an integrated HSM (low power, dedicated key storage hardware, etc.) in a very small form factor, easy to squeeze into any existing hardware design. Being MCU agnostic, the ATECC608 is able to interface with any microcontroller over I2C, but a single-wire protocol is also available if the GPIO is tight on the microcontroller. 

ST STSAFE-A110

ST’s STSAFE-A110 series is another external IC that can be used as an HSM. Very similar in functionality to the ATECC608, but not as power and space-efficient. It is also MCU agnostic and is interfacable through I2C.

Both ICs recommended above utilize I2C serial lines to facilitate communication with the MCU. But what happens if an attacker gains physical access to the device? It would be trivial to hook up a logic analyzer to the I2C lines and eavesdrop on all the juicy secrets being exchanged between them. Luckily, both ICs can “pair” with an MCU at manufacture time. This capability allows data exchanged over the I2C lines to be encrypted and authenticated, preventing potential bad guys from getting meaningful information. 

Verify, Verify, Verify!

When working with a potential HSM, from design through development, it is imperative to investigate where the keys are stored. Documentation and datasheets can all claim that things are secure, but some due diligence goes a long way. 

This due diligence has saved us in the past. We were working with an nRF5340 microcontroller and were playing around with Nordic’s plethora of security samples that exercise the integrated Arm CryptoCell co-processor. A Nordic example, “Crypto: Persistent Key Storage,” demonstrates how to generate and store a persistent key. We took the sample, threw it onto a dev kit, saw that it worked, and decided to integrate those findings into our application. Further down the road, we decided to take action to investigate where those keys were being stored.

It was straightforward to find where they were stored. All we did was read the flash contents of the microcontroller and search for the ASCII string “PSA KEY,” and there it was. Yep, it was that easy. 

Thankfully, we could pivot to using the nRF5340’s Key Management Unit (KMU) to store those keys and keep them out of flash securely, but the process was a precious lesson. Just because documentation and datasheets throw out desirable words like “secure” and “cryptography” does not mean that they will perform to your desired level of security. It is essential to know where and how your keys are stored down to the lowest level possible.

Alternatives To HSMs

What if hardware designs are already finalized? Can’t we stick the key in flash memory?

Storing keys in a Flash is one of the easiest ways to leak or compromise a key. Almost all microcontrollers have Flash read protection, protecting against anyone connecting a debugger to the MCU and reading flash contents. Flash read protection is NOT enough. If a potential attacker is motivated enough, has deep pockets, and has physical access to the device, they could pull the keys out of Flash. On top of that, software-based attacks that target vulnerabilities in the FW could cause the device to divulge information from Flash.

Making Flash More Secure

If you are still set on storing keys in Flash, there are some steps you can take to make it more secure. 

1. Enable read protection. We talked about how it is easy to work around but still worth it. Let’s make them work for it.
2. Use a Trusted Execution Environment (TEE). A TEE is an isolated execution environment separate from the main application in which trusted applications can operate on sensitive data. These distinct environments can reduce the attack surface available through the main FW application. 
3. Encrypt the key at rest using a key encryption key (KEK). If someone could compromise the stored key, they would be unable to do anything with it unless they had access to the KEK. However, this introduces a chicken and egg problem. Where do we store the KEK? Ideally, the KEK would not have to be stored. A KDF could be used to derive the KEK using some known secret as input, like a hardware ID from the MCU — as long as the hardware ID is not accessible through external means.

Even after taking these precautions, storing keys in a dedicated HSM is many times more secure than keeping it in Flash.

Even if hardware designs are finalized, I recommend re-considering the finality of the design. The FDA will be skeptical of any device submitted for approval that does not clearly outline its key storage methods. Utilizing an HSM that has already been certified by respected security groups will help ease that skepticism. The potential costs of a hardware re-design will be more than offset by the saved development/administrative time and the saved cost of avoiding a potential security breach. 

So, you’ve navigated the maze of key storage options and landed on a secure and FDA-friendly solution. Awesome! But let’s not pop the champagne just yet. Storing your keys is just the first step; now, you’ve got to use them effectively.

Key Usage

Now, we’ll break down the four pillars of effective cryptographic key management: Defining your keys’ roles, documenting their usage, rotating them to keep things fresh, and tracking their activity. Because, let’s face it, a key is only as good as how well you manage it.

Define Your Keys

Keys should have narrow and well-defined uses. The analogy of house keys works particularly well here. You wouldn’t want your car key to be the same key you use to get into your house, right? If that key gets stolen, your car and your home will be at risk instead of just your car. The same idea applies to cryptographic keys.

Document Your Keys

When designing a security architecture, creating and updating a glossary of all keys used in the system is extremely useful. Including information like the kind of key (e.g., symmetric/asymmetric), the algorithm it’s used for (ECDSA, AES-GCM, etc.), and a description of what it’s used for (session encryption key, key encryption key, key derivation key, etc.) will help your teammates understand what is being referenced when they are caught in the throes of semantic satiation.

Ensuring your team is on the same page with key terminology and their uses will help ensure that keys are used only for their intended purpose.

Rotate Your Keys

While using derived session scope keys for encryption is considered the best practice, it is still not infallible. It is possible for session keys to be leaked, and it is possible for a session key to get leaked while the session is still valid. The consequences of this leak may take time to be apparent. One way to limit the damage is to rotate your keys — derive new session keys — regularly. 

Rotating your session keys as often as possible would technically be the most secure, but you need to balance security with usability. While negotiating new session keys is not necessarily an intense process, it temporarily interrupts the ability to transmit encrypted data. The metric you can use to decide when to reroll keys can be flexible. It can be after a set amount of encryption operations, based on a unit of time (1 hour, one day, one week, etc.), or after a change of state (like a device going to sleep).

Track Your Keys

If you write firmware, you are probably used to dealing with all of the pitfalls of memory management, like making sure you free any malloced memory or staying away from dangling pointers. It can be helpful to employ that same kind of awareness when handling keys inside the firmware you write.

Just as you free-allocated memory as soon as you are done using it, key handles should only exist as long as they are still actively used. This approach applies particularly to ephemeral keys. An example would be an ephemeral asymmetric keypair generated for a Diffie-Hellman exchange. That key must be destroyed as soon as that exchange has been successfully completed. Key handles usually reference keys stored inside an HSM and should be treated as pointers. When a key is destroyed, the corresponding key handle should be set to a known sentinel value (most likely zero or NULL) to avoid accidentally referring to a no longer existing key. If handling a key outside of an HSM, then the memory location must be zeroized.

---

Takeaways

As you continue to design the security architecture for your implantable medical device, the importance of incorporating a Hardware Security Module (HSM) cannot be overstated. It’s the most reliable solution for key storage and offers efficient cryptographic processing. However, cryptographic key management is just one facet of a multi-layered security strategy. Remember to:

• Expect to use both asymmetric keys (most likely for authentication) and symmetric keys (most likely for encryption) in your security solution. 
• Prioritize generating or deriving keys only on the device that needs them. Avoid having to transmit keys over communication channels.
• Verify everything! Know where your keys are stored within hardware, down to the lowest level possible. 
• Only use keys for their narrowly defined purpose. Much like chips and dip at a party, avoid double dipping.

Related Articles

For those seeking additional information on security or connected device development, our other blog posts offer further help and insights: