Skip to Content

Improving Encryption Key Batteries

Each day, more of the world’s information and activity is moved onto digital platforms. Books, mail, music, gambling—the list goes on. 

As we further progress into the digital age, we must also recognize the corresponding security risks. It’s never been so easy for somebody you don’t know to gain access to your personal information. On a larger scale, an organization’s sensitive data is always in jeopardy if not properly secured. 

These modern problems require modern solutions. Similar to how you might put your money in a safe or keep valuables behind a locked door, digital users harness encryption keys to protect their information and data.

What Are Encryption Keys?

Encryption keys are random bits of information compiled specifically for scrambling and unscrambling data. Each one is built with an algorithm that keeps it unique and unpredictable. 

Encryption keys can be used to encrypt data, decrypt data, or both. The longer the key, the more difficult the code will be to crack. 

How Do Encryption Keys Work?

Encryption keys use a cipher to convert images, programs, and other information into indiscernible code. That data can only be deciphered by a matching key. This allows people to send and/or protect sensitive information without fear of interception. 

Encryption keys often have two types of keys:

  1. Data encryption keys (DEKs), which handle encryption and decryption of data 
  2. Key encryption keys (KEKs), which handle encryption and decryption of DEKs

These keys are created and stored on key management servers, as are their attributes. 

In addition to continuously maintaining digital access to these keys, the key management server must also be powered to keep data from being lost. To prevent system failures and keep encryption keys separate, they are often powered with batteries. 

Encryption key batteries are an essential component of cybersecurity because they help the key management server maintain a more private and regulated system.

Components of Encryption Key Management Systems

An encryption key management system comprises multiple parts. Protecting and operating an encryption key takes a lot of work. Encryption key maintenance is primarily regulated by the National Institute of Standards and Technology (NIST).

Key Life-Cycle

Before a key is activated, it must be assigned an estimated operational cryptoperiod, which means the creator must outline the amount of time it will be authorized for use. Typically, the more sensitive the information a key protects, the shorter its cryptoperiod will be. 

The list below outlines the stages of an encryption key’s full life-cycle.

  • Key creation: A key manager uses a cryptographically secure random bit generator to build and store the encryption key in a database. The key can be activated right away or set for future activation. The administrator will also choose who can access the key, if it can be deleted, and if it can be mirrored/copied.
  • Key use and rollover: This stage is when the key is accessible to authorized systems. If the key is rolled—deactivated to generate a new key—the key manager should retain and track all past instances of the key. Keys will be rolled manually or on an established schedule.
  • Key revocation: An administrator can revoke a key so it cannot be used for encryption and decryption requests. While a revoked key can be reactivated to access previously encrypted data, there may be restrictions surrounding the reasons it can be unrevoked.
  • Key back up: NIST requires that deactivated keys be archived so they can be recovered after a cryptoperiod expires. This allows the material to be reconstructed or reactivated if necessary.
  • Key deletion: Once a key is compromised or no longer in use, an administrator can delete it from the key manager storage database. This will make the recovery of the encrypted data impossible, as the decryption key will be lost indefinitely. While this safeguard protects data from being stolen, it also means you will no longer be able to access the data.

Physical Access to Servers

Encryption keys are built for security, so it makes sense that they must be properly secured. There are two main types of security that must be addressed: physical security and logical security.

Along with the use of a hardware security module (HSM), physical security involves the actual environment in which the key manager is located. This security plan should include safeguards for the considerations listed below.

  • Fire safety: The system environment should have up-to-date and effective fire suppression systems to prevent data from being burned.
  • Data interception: Sensitive data should always be encrypted to prevent an outside entity from being able to commandeer it.
  • Physical controls: Access to wiring and other critical systems should be limited to as few authorized personnel as possible.
  • Structural stability: The system environment should meet current standards for earthquakes, floods, and other extreme weather conditions.
  • Failure safeguard: If the power or temperature control fails, a backup system should be activated to protect the system from faltering.
  • Device management: Any device that has remote access to the key system should be managed and recorded in a permissions database.
  • Physical ports: FIPS 140-2, a security requirement outlined by NIST, notes that ports used for sending plaintext encryption keys should be used exclusively for that purpose.

FIPS 140-2 also lists four levels of increasing security that represent a corresponding threat level.

  • Security Level 1: “…No specific physical security mechanisms are required in a Security Level 1 cryptographic module beyond the basic requirement for production-grade components…. Security Level 1 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an unevaluated operating system…”
  • Security Level 2: “Security Level 2 enhances the physical security mechanisms of a Security Level 1 cryptographic module by adding the requirement for tamper-evidence…. Security Level 2 requires, at a minimum, role-based authentication in which a cryptographic module authenticates the authorization of an operator to assume a specific role and perform a corresponding set of services…”
  • Security Level 3: “…Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at physical access, use or modification of the cryptographic module. The physical security mechanisms may include the use of strong enclosures and tamper detection/response circuitry that zeroizes all plaintext CSPs when the removable covers/doors of the cryptographic module are opened…”
  • Security Level 4: “…At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access…. Security Level 4 also protects a cryptographic module against a security compromise due to environmental conditions or fluctuations outside of the module’s normal operating ranges for voltage and temperature…”

Logical Access to Servers

Once physical security has been established, you can focus on logical security. This is how you can separate the cryptographic components that hold the keys from other items in the network. 

There are three primary factors to consider for logical security.

  1. Interfaces: Section 4.2 of FIPS 140-2 outlines the criteria for separating logical interfaces.
    1. Security Levels 1 and 2: “…logical interface(s) used for the input and output of plaintext cryptographic keys, cryptographic key components, authentication data, and CSPs may be shared physically and logically with other ports and interfaces of the cryptographic module. “
    2. Security Levels 3 and 4: “the logical interfaces used for the input and output of plaintext cryptographic key components, authentication data, and CSPs shall be logically separated from all other interfaces using a trusted path, and plaintext cryptographic key components, authentication data, and other CSPs shall be directly entered into the cryptographic module.”
  2. DEK separation: If the encryption key manager is not physically separated in an HSM in a Level 1 environment, the DEK(s) must be logically separated from the encrypted data. This prevents the DEK(s) from being used by unauthorized users to decrypt said data. 
  3. KEK and DEK: Separating the DEK(s) from the KEK(s) renders the DEK(s) unusable if compromised through the database.

User/Role Access

The last necessary task is to establish the role of the user in an encryption key system. NIST encourages the concept of least privilege, meaning you only allow people the minimum access they need to perform their job. 

User access should be limited logically and physically to ensure security on both fronts. Keys can be restricted upon creation to only allow access for individuals with certain roles. 

Types of Encryption Keys

Depending on what you plan to use your encryption key for, there are two main strategies of encryption/decryption that are typically used: symmetric and asymmetric. 

Symmetric Keys

Symmetric encryption systems use one password as an encryptor and a decryptor. This is a very secure option for storing information. However, because the encryptor and decryptor are on a single key, information can sometimes be stolen or leaked when the password is shared. 

When using symmetric encryption, you are encouraged to update the key frequently to improve your security. This type of key is often used for data-at-rest, such as information stored in a database that can be accessed by authorized users.

Asymmetric Keys

Similar to symmetric keys, asymmetric encryption keys use a complex algorithm to secure data. The difference is that an asymmetric system has two keys, one for encryption and one for decryption. These two keys are referred to as a key pair and can only be used together. This way, the encryption key can be shared freely with the public, while the decryption key is kept private—only to be used for accessing the encrypted data submitted by the public.

Asymmetric encryption is considered more reliable because only the holder of the private key can access the encrypted information. When the key pair is activated, the public key owner will get a message requesting a passcode. 

For optimal security, the passcode should be delivered manually, but some software allows users to store the code so decryption is automatic upon receiving the message. These keys are used to secure data-in-motion. One asymmetric encryption key example is a virtual private network (VPN).

City Labs NanoTritium™ Batteries for Encryption Keys

The cryptoperiod for symmetric keys is shorter than that for asymmetric keys due to necessary cipher updates, but the key server still must have a power supply to keep the system up and running. 

Current batteries for encryption keys do not last a sufficient amount of time and require replacements for long-term projects. Battery efficiency can also decrease based on usage and may be influenced by extreme environmental conditions. 

At City Labs, we have developed small betavoltaic batteries powered by tritium decay that can output energy for over 20 years. Our batteries have a consistent and predictable drop-off that does not change based on usage. Many of our partners are still using our devices for a variety of applications. 

See how our NanoTritium™ technology works to power encryption keys and other microelectronics.

PSP Power Source Package Content

City Labs batteries can also be confidently placed in convenient locations. We have a patent for putting power sources directly on the circuit board to hide them and make the energy easily accessible. 

Our Power Source Package patent provides increased security for your encryption key management server by eliminating the risk of power outages and sheltering your battery in a safer place. 

Extending the Life Cycle of Encryption Keys

City Labs NanoTritium™ batteries will greatly increase the lifespan of your encryption keys, allowing you to keep data safe for longer periods of time without maintenance under a wide range of temperatures and environmental conditions. This feature is especially useful for security servers in remote locations or keys in places that are not easy to access. 

Check out our tritium battery products or send us a message to learn more about what City Labs can do for you. 

The Nuclear Battery Company with a Vision

Reach out to us to discuss your platform’s power needs and how City Labs’ power solutions can help it run longer and more efficiently.

Contact Us Today
Scroll to Top