CON.1 Cryptographic Concept

Description

Introduction

Cryptography is a widely used means of ensuring information security with respect to the protection objectives of confidentiality, integrity and authenticity. It makes it possible, for example, to encrypt information so that its content cannot be read without the corresponding key. In symmetric methods, the same key is used for both encryption and decryption; in asymmetric methods, one key is used for encryption and another for decryption.

In a wide variety of IT environments, such as client-server environments, locally stored information as well as information to be transmitted between communication partners can be effectively protected using cryptographic methods. Cryptographic methods can be implemented in hardware or software components (hereinafter collectively referred to as hardware or software with cryptographic functions).

The technical use of cryptographic methods alone is not sufficient to guarantee the confidentiality, integrity and authenticity of information. Organisational measures are also required. In order to protect information effectively, it is necessary to address the topic of cryptography holistically within the framework of a cryptographic concept.

Objective

This building block describes how a cryptographic concept should be created and how it can be used to cryptographically protect information in institutions.

Scope and Modeling

The building block CON.1 Cryptographic Concept is to be applied once to the information network. This building block addresses organisational and technical requirements for hardware or software with cryptographic functions as well as cryptographic methods. The core IT tasks associated with the operation of hardware or software with cryptographic functions are not covered here. For these, the requirements of the building blocks in layer OPS.1.1 Core IT Operations must be met.

How applications (e.g. end-to-end encryption for emails), individual IT systems (e.g. laptops) or communication links can be cryptographically secured is likewise not the subject of this building block. These topics are covered in the corresponding building blocks of the layers APP Applications, SYS IT Systems and NET Networks and Communications.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information networks, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block CON.1 Cryptographic Concept.

Inadequate Key Management for Encryption

Inadequate key management could result in unencrypted information being exposed during an attack. For example, due to a lack of rules, encrypted information along with the corresponding keys may be stored on the same storage medium or transmitted unencrypted over the same communication channel. In these cases, anyone who can access the storage medium or communication channel can decrypt the information when symmetric methods are used.

Inadequate or missing key management can also threaten the availability of applications, for example when cryptographic functions can no longer be used after the validity period of keys or certificates has expired.

Violation of Legal Frameworks when Using Hardware or Software with Cryptographic Functions

When institutions use hardware or software with cryptographic functions, they must comply with various legal frameworks. In some countries, for example, cryptographic methods may only be used with government approval, meaning that the use of hardware or software with strong cryptographic functions is significantly restricted. This can result in recipients in such countries being unable to read encrypted data sets, because they are not permitted to use the required hardware or software with cryptographic functions. In the worst case, recipients could even be committing an offence if they were to use the required hardware or software with cryptographic functions without authorisation. Or this situation could lead those involved in communication to exchange the information unencrypted, which in turn can give rise to a multitude of threats to the confidentiality, integrity and authenticity of the exchanged information.

A situation can even arise where the legal provisions of one country require the use of appropriate cryptography, while those of another country expressly prohibit this or provide for a state capability to decrypt. For example, European data protection regulations may require that appropriate cryptographic methods be used to protect personal data. If communication is to take place from a corresponding European country to another country in which the use of cryptography is heavily regulated and not approved in the specific case, then legal communication between two persons from the respective countries is not possible.

Loss of Confidentiality or Integrity of Information through Misuse

If cryptographic functions are not used, or not used correctly, they cannot provide the intended protection for information. For example, if an institution uses hardware or software with cryptographic functions that is very complicated to operate, users might forgo encryption and instead transmit the information in plaintext. This would allow the transmitted information to be intercepted in an attack.

If hardware or software with cryptographic functions is operated incorrectly, this can also result in confidential information being captured in an attack — for example when it is transmitted in plaintext because plaintext mode was accidentally activated.

Vulnerabilities or Errors in Hardware or Software with Cryptographic Functions

Vulnerabilities or errors in hardware or software with cryptographic functions impair the security of the cryptographic methods used. They can, for example, result in the information protected by them being read.

Many cryptographic methods rely on random number generators to generate secure keys, e.g. for a communication connection. Even if such a method is considered principally and conceptually secure, an error in the hardware or software implementation can result in predictable random numbers being generated, which means the associated cryptographic keys can also be reconstructed. This can allow encrypted information to be spied out, which in turn can have far-reaching consequences.

Failure of Hardware with Cryptographic Functions

Hardware with cryptographic functions (e.g. smart cards for drive encryption) can fail due to technical defects, power outages or deliberate destruction. This could mean that already encrypted information can no longer be decrypted for as long as the required hardware is unavailable. As a result, entire process chains can come to a standstill, for example when other applications depend on that information.

Insecure Cryptographic Algorithms

Insecure or outdated cryptographic algorithms can be broken with minimal effort in an attack. For encryption algorithms, this means that the original plaintext can be determined from the encrypted text without any additional information being available in the attack, such as the cryptographic key used. If insecure cryptographic algorithms are used, attackers can circumvent the cryptographic protection and thus access the institution’s sensitive information. Even if an institution exclusively uses secure (e.g. certified) hardware or software with cryptographic functions, communication can still become insecure. This is the case, for example, when the communication partner uses cryptographic methods that do not correspond to the state of the art.

Errors in Encrypted Information or Cryptographic Keys

If information is encrypted and the ciphertext is subsequently modified, it may no longer be possible to correctly decrypt the encrypted information. Depending on the mode of operation of the encryption routines, this can mean that only a few bytes or all information is lost. If no backup exists, such information is permanently lost. This can also be exploited in attacks by modifying only a minimal portion of the ciphertext, causing the encrypted information to be completely lost.

An error in the cryptographic keys used can have even more critical consequences. Changing even a single bit of a cryptographic key means that all information encrypted with it can no longer be decrypted.

Compromise of Cryptographic Keys

The security of cryptographic methods depends critically on how confidential the cryptographic keys used remain. Consequently, an attack typically attempts to obtain or determine the keys being used. This could succeed, for example, by reading out volatile memory or by finding unprotected keys stored, for example, in a backup or a configuration file. If the keys used and the cryptographic method employed are known, the information can be decrypted relatively easily.

Forged Certificates

Certificates serve to bind a public cryptographic key to a person, an IT system or an institution. This binding of the key is in turn cryptographically secured, often by a trusted third party, using a digital signature.

The certificates are used by third parties to verify digital signatures of the person, IT system or institution identified in the certificate. Alternatively, the key stored in the certificate can be used for an asymmetric encryption method to encrypt information for the certificate holder.

If such a certificate is forged, digital signatures are incorrectly verified as valid and attributed to the person, IT system or institution named in the certificate. Or information is encrypted with a potentially insecure key and transmitted.

Requirements

The following are the specific requirements of the building block CON.1 Cryptographic Concept. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and reviewed in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. These should be filled to the extent that it is sensible and appropriate.

Exactly one role should bear Primary responsibility. There may also be Additional responsibilities. If one of these additional roles has primary responsibility for fulfilling a specific requirement, that role is listed in square brackets after the heading of the requirement. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be met as a priority for this building block.

CON.1.A1 Selection of Suitable Cryptographic Methods (B) [Subject Matter Experts]

Suitable cryptographic methods MUST be selected. It MUST be ensured that established algorithms are used that have been extensively examined by experts and for which no security vulnerabilities are known. Currently recommended key lengths MUST also be used. When selecting an appropriate key length, consideration SHOULD be given to how long the cryptographic method is intended to be used. For longer periods of use, correspondingly longer key lengths SHOULD be employed.

CON.1.A2 Data Backup when Using Cryptographic Methods (B) [IT Operations]

In data backups, cryptographic keys MUST be stored or kept by IT Operations in such a way that unauthorised persons cannot access them. Long-lived cryptographic keys MUST be stored offline, outside the IT systems in use.

For long-term storage of encrypted information, regular checks SHOULD be carried out to determine whether the cryptographic algorithms and key lengths used are still suitable for the respective information. IT Operations MUST ensure that encrypted stored information can still be accessed even after extended periods of time. Hardware or software with cryptographic functions that is used SHOULD be archived.

CON.1.A4 Appropriate Key Management (B)

An appropriate key management system for cryptographic hardware or software MUST specify how keys and certificates are generated, stored, exchanged and subsequently deleted or destroyed. It MUST also specify how the integrity and authenticity of the keys is ensured.

Cryptographic keys SHOULD always be generated using suitable key generators and in a secure environment. Pre-set keys in hardware or software with cryptographic functions SHOULD be replaced (with the exception of public certificates). A key SHOULD ideally serve only one purpose. In particular, different keys SHOULD be used for encryption and signature creation. Cryptographic keys SHOULD be exchanged using methods considered secure.

If public keys from third parties are used, it MUST be ensured that the keys are authentic and the integrity of the key data is guaranteed.

Secret keys MUST be stored securely and protected against unauthorised access. All cryptographic keys SHOULD be changed sufficiently frequently. There SHOULD generally be a rule governing how expired keys and associated signatures are handled. If the validity of keys or certificates is restricted in time, the institution MUST ensure that the time-restricted certificates or keys are renewed in good time.

A procedure SHOULD be defined for the event that a private key is disclosed. All generated cryptographic keys SHOULD be stored and managed securely.

Standard Requirements

Together with the basic requirements, the following requirements represent the state of the art for this building block. They SHOULD generally be met.

CON.1.A3 DISCONTINUED (S)

This requirement has been discontinued.

CON.1.A5 Secure Deletion and Destruction of Cryptographic Keys (S) [IT Operations, Users]

Private keys that are no longer required SHOULD be securely deleted or destroyed. The procedures and methods used to delete or destroy private keys that are no longer needed SHOULD be documented in the cryptographic concept.

CON.1.A6 DISCONTINUED (S)

This requirement has been discontinued.

CON.1.A7 DISCONTINUED (S)

This requirement has been discontinued.

CON.1.A8 DISCONTINUED (S)

This requirement has been discontinued.

CON.1.A9 Defining Criteria for the Selection of Hardware or Software with Cryptographic Functions (S) [Subject Matter Experts]

The cryptographic concept SHOULD specify the criteria and requirements used to select hardware or software with cryptographic functions. The following aspects SHOULD be considered and documented in the cryptographic concept:

• functional scope,

• interoperability,

• cost-effectiveness,

• protection against incorrect operation and malfunctions,

• technical aspects,

• personnel and organisational aspects,

• lifespan of cryptographic methods and the key lengths used, as well as

• legal frameworks

• international legal aspects such as export and import restrictions for hardware or software with cryptographic functions, if the cryptographic methods are also used abroad

• data protection

Preference SHOULD generally be given to certified hardware or software with cryptographic functions, where the certification covers the relevant aspects of cryptography.

CON.1.A10 Creation of a Cryptographic Concept (S)

Based on the institution’s general security concept, a cryptographic concept for hardware or software with cryptographic functions SHOULD be created. The cryptographic concept SHOULD describe:

• how backups of cryptographic keys are performed,
• how key management for cryptographic keys is structured, and
• how the crypto register is maintained.

The cryptographic concept SHOULD also describe how it is ensured that cryptographic functions of hardware or software are securely configured and correctly used. All technical specifications for hardware and software with cryptographic functions SHOULD be described in the cryptographic concept (e.g. requirements, configuration or parameters). The BSI TR 02102 SHOULD be considered when selecting appropriate cryptographic methods.

If the cryptographic concept is changed or deviated from, this SHOULD be agreed with the ISO and documented. The cryptographic concept SHOULD be known to all those who use cryptographic methods. Furthermore, it SHOULD be binding for their work. In particular, IT Operations SHOULD implement the cryptographic specifications of the cryptographic concept.

CON.1.A15 Response to Practical Weakening of a Cryptographic Method (S)

The institution SHOULD review at least annually, using the crypto register, whether the cryptographic methods used and their associated parameters are still sufficiently secure and free of known vulnerabilities.

The cryptographic concept SHOULD define and document a process for the event that vulnerabilities arise in cryptographic methods. It SHOULD be ensured that the weakened cryptographic method is either secured or replaced by a suitable alternative, so that no security risk arises.

CON.1.A19 Creation of a Crypto Register (S) [IT Operations]

For each group of IT systems, the following information SHOULD be recorded in the crypto register:

• Purpose (e.g. hard disk encryption or encryption of a communication connection)
• Responsible parties
• Cryptographic method used
• Hardware or software with cryptographic functions used
• Security-relevant parameters used (e.g. key lengths)

Requirements for High Protection Needs

The following are examples of proposed requirements for this building block that go beyond the level of protection corresponding to the state of the art. These proposals SHOULD be considered for high protection needs. The specific determination is made within the framework of an individual risk analysis.

CON.1.A11 Testing of Hardware with Cryptographic Functions (H) [IT Operations]

Test procedures for hardware with cryptographic functions SHOULD be defined in the cryptographic concept. Before hardware with cryptographic functions is deployed, it should be tested whether the cryptographic functions work correctly.

If an IT system is changed, it SHOULD be tested whether the cryptographic hardware used still functions properly. The configuration of the cryptographic hardware SHOULD be reviewed regularly.

CON.1.A12 DISCONTINUED (H)

This requirement has been discontinued.

CON.1.A13 DISCONTINUED (H)

This requirement has been discontinued.

CON.1.A14 DISCONTINUED (H)

This requirement has been discontinued.

CON.1.A16 Physical Protection of Hardware with Cryptographic Functions (H) [IT Operations]

The cryptographic concept SHOULD specify how IT Operations ensures that hardware with cryptographic functions cannot be accessed physically without authorisation.

CON.1.A17 Emissions Security (H) [IT Operations]

It SHOULD be examined whether additional measures regarding emissions security are necessary. This SHOULD in particular be the case when classified government information (VS) at the classification levels VS-CONFIDENTIAL and above is being processed. Measures taken regarding emissions security SHOULD be documented in the cryptographic concept.

CON.1.A18 Cryptographic Replacement Hardware (H) [IT Operations]

Hardware with cryptographic functions (e.g. hardware tokens for two-factor authentication) SHOULD be kept in stock. The cryptographic concept SHOULD document for which hardware with cryptographic functions replacement hardware is available and how it can be exchanged.

CON.1.A20 Tamper Detection for Hardware or Software with Cryptographic Functions (H)

Hardware and software with cryptographic functions SHOULD be monitored for tampering attempts.

Additional Information

Good to Know

The International Organization for Standardization (ISO) addresses the topic of cryptography in the standard ISO/IEC 27001:2013 in Annex A.10 with two guidelines.

For the selection of encryption methods and key lengths, the technical guideline “BSI-TR-02102: Cryptographic Methods: Recommendations and Key Lengths” from the BSI should be consulted.

The Information Security Forum (ISF) has developed requirements for cryptographic concepts in its standard “The Standard of Good Practice for Information Security” in the “Area TS2 Cryptography”.