The provision of efficient and effective cryptography relies on close integration of application program interfaces (APIs), cryptographic service providers (CSPs) and key management.
However, implementations of hardware-based cryptography normally required bespoke vendor APIs to support applications. Key management functionality is also normally vendor specific. Accordingly, it is not unusual for a large enterprise or organization to have an encryption system that utilises several separate key management systems that do not interoperate without manual key management operations taking place.
It is worth noting that a number of standards (de facto and Standards Bodies) have been developed, but they deal with specific instances of cryptography, business sectors or products. Some of these standards are listed in Table 1 below.
With any of the APIs listed in Table 1, there is a problem of vendor implementation and vendor lock-in, coupled with reluctance of vendors to build solutions that support high levels of integration between other vendor's products and services. This gives rise to the following issues:                1. currently available cryptographic APIs that provide an interface to a cryptographic service require a number of pre-determined values to be defined before an API call is made, these pre-determined values including key values/sizes, cryptographic algorithms, modes of operation, padding schemes, and additional values (initialization vectors, etc).        2. if one were to standardize on a specific vendor, then either the bespoke APIs or Key management implementations of the vendor would need to be integrated into all relevant applications;        3. change of vendor requires a change to these applications;        4. reliance on a particular provider.        
TABLE 1StandardAreaDefining bodyPKCS#1-16Various uses of RSA based AsymmetricRSA Labsbased cryptographyX 509Exchange and use of Asymmetric keysANSIMSCAPICryptographic support for MicrosoftMicrosoftapplicationsBSAFECryptographic toolkits providersRSAControlKey ManagementIBMVectorsLMK VariantsKey ManagementThalesACLKey ManagementnCipherGSS-APIAPI FrameworkIETFX9.24 pt1/2Key Management BankingANSI
It is possible for applications to adopt certain standards (e.g. cryptographic token interface standard PKCS#11) to try to de-couple vendor specific Application API implementations.
However, key management and cryptographic control mechanisms that are required to provide confidentiality, integrity and authentication to data within applications are currently embedded in the application, which makes changes and alterations difficult and costly to implement. Therefore, even if the application API is decoupled in the case of PKCS#11, there is still a reliance on the vendor's implementation and key management solution.
Also wholesale adoption of general encryption APIs such as PKCS#11 do not allow for deployment of application-specific cryptographic mechanisms e.g. for the banking sector, PIN block translation, card verification value, CVV generation, etc.
Another primary concern is the control over the usage of the cryptographic function. The cryptographic function should be available to entitled users only. If it is not possible to distinguish between an attacker and an entitled user, then the strongest cryptographic algorithm is rendered useless. Additionally, the scenario in which the cryptographic function can be used by an entitled user needs to be controlled. For example, it may be possible that two users, Alice and Bob, are both entitled users of the cryptographic functionality, but the security model may require that Alice can only encrypt data to Bob and Bob can only decrypt data from Alice. Without additional controls, it would be possible for both Alice and Bob to perform both encryption and decryption on data in either direction due to the nature of symmetric algorithms.
Accordingly, it is desirable to provide a flexible approach to defining the cryptographic access and control mechanisms required by applications to protect sensitive key material and data.
USPTO Backgrounds
USPTO Backgrounds