User Tools

Site Tools


cgl:cglgapproposalcgos.3.3

Contents

Title

Unified Cryptographic Framework

Description

To provide a cryptographic framework that supports encryption and message hashing for both kernel and user applications, secure tamper-proof storage for security-relevant data such as keys, and registration of cryptographic capabilities.

The CGOS needs to provide a unified framework for optimized implementations of common cryptographic (encryption and message hashing) algorithms.

Carrier grade solutions rely on communication protocols that have stringent security requirements. Typically, these protocols are based on standard security application providers such as SSL, SSH, IKE and JCE.

Data integrity is accomplished through mechanisms (message hashing) that check that data transmitted across the network or stored on/retrieved from disk without encryption are not modified. Data confidentiality is accomplished through mechanisms (encryption) that convert the data to a form not easily reversible, before being transmitted or stored. The use of both encryption and message hashing for data that are transmitted or stored demands a cryptographic framework that is available to both the kernel and user applications and that transparently makes use of whatever hardware encryption capabilities are available.

A prerequisite to the security capabilities described above is the ability to store in a secure, tamper-proof way security-relevant data, such as keys used to verify the integrity of downloaded data. Keys can be loaded during system assembly, and additional keys can be provided using a secure mechanism after the system is started. Such a mechanism is almost always a combination of hardware, operating system and firmware. See also Trust Mechanisms (CGOS-3.1).

A unified cryptographic framework must expose to security providers a common interface to algorithms not only for various encryption algorithms (at the very minimum 3DES and AES) but also for message hashing (MD5, SHA1), message signing (RSA, DSA, DH) and random number generation. See the RSA cryptographic token interface standard PKCS #11 [19].

Hardware acceleration is also desirable for carrier grade components that use encryption. The cryptographic framework must offer mechanisms whereby device drivers can register the cryptographic hardware. A device with a cryptographic capability (key store, encryption algorithm) must be able to register the capability with the cryptographic framework. Registration includes, for example, the type of cryptographic capability, available algorithms, and number of contexts. When a driver initializes, it must register any cryptographic capabilities possessed by the device(s) it controls.

When a kernel thread or user process requests that a particular algorithm be used, the cryptographic framework must try to use the most efficient implementation based on the availability of resources in a transparent manner.

Algorithms must be easy to export/import. Cryptographic keys must be easily reduced to 56 bits, or cryptography must be easy to switch off.

Priority

Medium

Use Cases

TBD: blame Joe.

Scenarios

References

SCOPE Alliance Carrier Grade Operating Systems, Gap Analysis v2.0, CGOS-3.3


Internal Use Only

State: [OPEN]

Section: [Security]

Date opened: [2008.09.09]

Submitter: [SCOPE Alliance]

Owner: [SCOPE Alliance]

Date integrated: []

Integrated into: []

Resolution Comments: []

Proof of Concept: []

cgl/cglgapproposalcgos.3.3.txt · Last modified: 2016/07/19 01:22 (external edit)