Manage Crypto

Extracting and assessing the cryptographic algorithms of an application in the context of post-quantum security is crucial for several reasons. Quantum computers pose a significant threat to classical cryptographic algorithms, potentially rendering them insecure. By identifying and evaluating the cryptographic algorithms used, organizations can:

1. Identify Vulnerabilities: Determine which algorithms are vulnerable to quantum attacks.
2. Plan for Transition: Develop a roadmap to transition to post-quantum cryptographic algorithms.
3. Ensure Compliance: Meet regulatory requirements and standards for post-quantum security.
4. Maintain Security: Protect sensitive data and communications from future quantum threats.

This proactive approach ensures long-term security and resilience against the evolving landscape of quantum computing.

TrustSource supports this approach with specific tools such as ts-scan respectively ts-deepscan. These scanners may determine crypto algorithms in source code and transfer this data to TrustSource for further processing. To learn how you may achieve this, see ts-scan documentation for details. 

The Crypto Management Process

To simplify the approach, we defined four steps to tackle the Crypto Process. The details of each step are described in the following sub-chapters.

1. Identify

To identify algorithms use our ts-scan tool. It allows to scan sources for the use of crypto algorithms. These findings can be stored locally or transferred to TrustSource for further processing. Given you transfer them, you will add them into a "module", our representation of what you have scanned.

PLEASE NOTE: If you have several artefacts residing in one repository and scan the whole repository in one run, it will be difficult for TrustSource to associate the findings with the correct scans! We highly recommend to keep the scope of the assessment in sync with the delivery artefacts you have created inside your project structure. 

PLEASE NOTE: The risk classes for the algorithms and their interaction with Security Requirements can be managed on a corporate level. This may be refined in a project. However, see the "Governing Crypto Risk" article for more details. 

2. Evaluate Usage

In the next step you evaluate the use of the algorithms. Therefor select the module of choice and go to  SETTINGS > ENCRYPTION. In the list presented, you will see the algorithms ts-scan has been able to identify in the sources. 

If you are missing some, or have additional information e.g. through binaries included but not scanned,  you may add additional algorithms manually. However, it is currently not possible to add private algorithms. If you have this requirement, please contact our support to resolve this issue.

Now you may look at the implementation and the usage of each algorithm identified. Are they really used for any purpose? Will thy fit to the required security level concerning the demand? Does the algorithm maybe cause a export issue (see Manage Export Controls for more information)?

According to your observations you may decided to eliminate or change algorithms. 

3. Document

Finally you may need to prepare documentation for all existing algorithms. The table has a set of fields allowing you to achieve this documentation.

The table holds the following information:

1. Algorithm

In encryption, algorithms are used to transform plaintext into ciphertext (and vice versa). Here you select the name of the algorithm identified. You should add something here only, if you will want to add an algorithm manually. 

2. Primitive

In cryptography, primitives are the basic cryptographic operations like hash functions (e.g., SHA-256), encryption schemes (e.g., AES), and digital signatures.

3. Parameter Set Identifier

In elliptic curve cryptography (ECC), a parameter set identifier specifies the curve parameters (e.g., curve equation, base point) used for encryption and key generation.

4. Elliptic Curve

The mathematical curve defined by an equation of the form y² = x³ + ax + b, used  for efficient and secure key generation and encryption. Meanwhile often applied for digital signatures, key exchange, and encryption.

5. Execution Environment

The runtime environment in which a software application or cryptographic algorithm operates. This includes the hardware, operating system, and any middleware or libraries that the software interacts with. Ensuring the security of the execution environment is crucial for risk management in software development.

6. Implementation Platform

The specific hardware or software platform on which a cryptographic algorithm or software application is implemented. This could be a specific CPU, GPU, or a virtualized environment. The choice of implementation platform can affect the performance and security of the cryptographic operations.

7. Certification Level

A measure of the security assurance provided by a cryptographic module or software application, often determined through formal evaluation processes. Certification levels are defined by standards like FIPS 140-2, which specifies security requirements for cryptographic modules. Higher certification levels indicate more rigorous security testing and assurance.

8. Padding

This addresses the process of adding extra data to a message or data block to ensure it meets specific size requirements or to enhance security. Padding is used in encryption to ensure that the plaintext fits the block size of the encryption algorithm and to prevent certain types of attacks. Examples include PKCS#7 padding.

9. Cryptographic Function

A function that performs a cryptographic operation, such as encryption, decryption, hashing, or digital signing.

10. Classical Security Level

The level of security provided by a cryptographic algorithm against classical (non-quantum) attacks. This is a setting, that should be provided from your corporate security manager(s). 

11. NIST Quantum Security Level

The level of security provided by a cryptographic algorithm against quantum attacks, as defined by the National Institute of Standards and Technology (NIST). This also should be provided centrally. But if you do not receive the data, you may have a look into the referenced study.

12. Applied

Check this, when you or the algorithms of the app use this algorithm. If you are not sure, comment accordingly but keep the "used". You may contact our support to get access to a  preliminary version of ts-scan, that is able to assess call graphs. 

13. Comment

Allows to leave working remarks or comments for a reviewer.

You must not complete all fields. But the more information you provide, the simpler export or import declarations may be created (and nobody will return and bother you with questions). 

4. Declare

To declare the state of algorithms, TrustSource allows to export a Cryptographic Bill of Materials or CBOM as part of your SBOM. To do so, you select the OUTBOUND > SBOM and create a new SBOM for the project or module of choice. Then open the SBOM and find the "Export as CycloneDX" button in the header.

This button has a selector included. You may select the type of export, either you export a standard Software Bill of Materials (SBOM), a Cryptographic Bill of Materials (CBOM) or an SBOM including the SBOM section.

SPDX does not yet provide a specification on the handling of specific crypto information. Neither in version 2.3 nor in version 3.0. Most likely this will come as an enhancement for v3.0. However, we will wait for the specification to be available to not conflict with the standard.