ASN1js and PKIjs - a year after creation
Almost a year ago I talked about the new PKIjs and ASN1js libraries . It's time to talk about the development of these libraries. For ASN1js, mostly cosmetic changes were made during this time. Of the significant changes, only the possibility of converting any ASN.1 objects into the JSON format can be noticed. But with PKIjs there have been more significant changes.
So, the current main features of PKIjs:
To begin with about the implementation of signatures. I have already listed all the algorithms used, but it should be noted that PKIjs allows you to create various types of cryptographic objects that will use all of these algorithms:
For all these types of cryptographic objects, there are convenient “helpers” (helpers) that allow you to obtain the internal structure of previously encoded objects, create a new structure of objects or sign internal data, as well as verify the existing signature. Also for each type there is a separate example of its use with the use of all possible signature algorithms.
We now turn to the description of the implementation of work with encryption. The creators of the Web Cryptography API based the standard on the latest information on cryptographic algorithms. Given this, we can say that the Web Cryptography API has tried to cut off all the outdated cryptography world. Since PKIjs is based solely on the Web Cryptography API, therefore, PKIjs had to implement the latest encrypted data generation algorithms (CMS Enveloped Data) and cut off the old, already familiar to everyone, algorithms.
')
PKIjs implements the ability to work with all types of recipients of encrypted CMS messages:
Common to all types of recipients of encrypted CMS messages: in PKIjs, it is possible to use two algorithms as the main data encryption algorithm - AES-CBC and AES-GCM. Technically, it is also possible to use AES-CTR, however, for this algorithm there are no generally accepted OIDs and algorithm parameters that can be used in CMS messages.
First, I’ll talk about the main types of recipients of encrypted messages - “KeyTransRecipientInfo” and “KeyAgreeRecipientInfo”. The type “KeyTransRecipientInfo” is currently only possible for recipients for whom there are X.509 certificates signed with RSA algorithms (RSASSA-PKCS1-v1_5 and RSA-PSS). When implementing encryption for the recipient with the “KeyTransRecipientInfo” type, the RSA-OAEP asymmetric encryption algorithm (RSASSA-OAEP) is used. For RSA-OAEP, only MGF1 is strictly applied, however, it is possible to specify a hash algorithm from SHA-1 to SHA-512. For recipients whose certificates contain signatures on ECC (Elliptic Curve Cryptography), only the “KeyAgreeRecipientInfo” recipient type is available. This type uses a more sophisticated KEK (key encryption key) generation scheme: an ephemeral key is generated on the ECDH algorithm, and then a special “key derivation function” (KDF) is performed, based on the use of hashing algorithms. Here, the user can specify both the type of elliptic curve used (secp256r1, secp384r1 or secp521r1), as well as the type of hashing algorithm used in KDF.
With the “KEKRecipientInfo” type, everything is quite simple: the user sends the selected session key encryption algorithm to the function, as well as the buffer with the saved key for this algorithm. PKIjs in the future it remains only to use the previously transmitted data. The work with the “PasswordRecipientInfo” recipient type is slightly more complicated: the “key encryption key” is formed as a result of the PBKDF2 algorithm, and the session key is already encrypted with this data. Also, it is technically possible to use the HKDF algorithm, however, there is the same problem as with AES-CTR: there are no generally accepted OIDs for use in CMS Enveloped Data.
I will also say that at present PKIjs can generate types of cryptographic messages that are not supported, for example, in the latest releases of OpenSSL, as well as in Microsoft CryptoAPI (and CNG). For example, in OpenSSL there is no possibility (through a standard console application) to decrypt data using PBKDF2 + AES-KW, and in Microsoft CryptoAPI there is no support for the “dhSinglePass-stdDH-sha1kdf-scheme” and “dhSinglePass-stdDH-sha512kdf-scheme” schemes , as well as the recipient types KEKRecipientInfo and PasswordRecipientInfo.
A more detailed description of the encryption capabilities is provided in the README file located in the directories of encryption examples using a certificate , as well as using a password .
In conclusion, I will say that this library continues to grow, but with the help of Peculiar Ventures . Library features will only expand, stay tuned. I would be grateful for the constructive comments, as well as the description of projects implemented using PKIjs. For advice on working with the library you can contact me, its author directly.
So, the current main features of PKIjs:
- Full Web Cryptography API support;
- Limited use in the iPhone (through the use of Safari), and in Android applications (Google Chrome);
- The number of examples has expanded. In particular, examples of using PKIjs for checking signatures in PDF files and for checking signatures in S / MIME have been added;
- Use of all signature algorithms from the Web Cryptography API:
- RSASSA-PKCS1-v1_5 (PKCS # 1 v1.5);
- RSA-PSS (PKCS # 1 v2);
- ECDSA (signature on ECC, Elliptic Curve Cryptography);
- The first implementation of the "certificate chain verification engine" in pure JavaScript and passing the main NIST tests;
- The first and so far the only implementation of "Suite B" for signing and encrypting data as a CMS (Cryptographic Message Syntax) in "open-source" in pure JavaScript;
- Signed CMS using ECDSA;
- Encryption using ephemeral-static ECDH;
- Using AES-CBC and AES-GCM;
- Using an extended list of hashing algorithms: from SHA-1 to SHA-512;
- The ability to create encrypted messages based on the use of a password using the AES series of algorithms;
To begin with about the implementation of signatures. I have already listed all the algorithms used, but it should be noted that PKIjs allows you to create various types of cryptographic objects that will use all of these algorithms:
- X.509 certificates;
- X.509 CRL (Certificate Revocation List);
- Requests to create certificates of the PKCS # 10 format;
- OCSP requests;
- OCSP responses;
- TSP requests;
- TSP replies;
- CMS Signed Data;
For all these types of cryptographic objects, there are convenient “helpers” (helpers) that allow you to obtain the internal structure of previously encoded objects, create a new structure of objects or sign internal data, as well as verify the existing signature. Also for each type there is a separate example of its use with the use of all possible signature algorithms.
We now turn to the description of the implementation of work with encryption. The creators of the Web Cryptography API based the standard on the latest information on cryptographic algorithms. Given this, we can say that the Web Cryptography API has tried to cut off all the outdated cryptography world. Since PKIjs is based solely on the Web Cryptography API, therefore, PKIjs had to implement the latest encrypted data generation algorithms (CMS Enveloped Data) and cut off the old, already familiar to everyone, algorithms.
')
PKIjs implements the ability to work with all types of recipients of encrypted CMS messages:
- KeyTransRecipientInfo (encryption of the session key by an asymmetric algorithm);
- KeyAgreeRecipientInfo (encrypting a session key based on a “shared secret”);
- KEKRecipientInfo (encryption of the session key based on the previously known value of "key encryption key");
- PasswordRecipientInfo (encryption of the session key based on data derived from the specified password);
Common to all types of recipients of encrypted CMS messages: in PKIjs, it is possible to use two algorithms as the main data encryption algorithm - AES-CBC and AES-GCM. Technically, it is also possible to use AES-CTR, however, for this algorithm there are no generally accepted OIDs and algorithm parameters that can be used in CMS messages.
First, I’ll talk about the main types of recipients of encrypted messages - “KeyTransRecipientInfo” and “KeyAgreeRecipientInfo”. The type “KeyTransRecipientInfo” is currently only possible for recipients for whom there are X.509 certificates signed with RSA algorithms (RSASSA-PKCS1-v1_5 and RSA-PSS). When implementing encryption for the recipient with the “KeyTransRecipientInfo” type, the RSA-OAEP asymmetric encryption algorithm (RSASSA-OAEP) is used. For RSA-OAEP, only MGF1 is strictly applied, however, it is possible to specify a hash algorithm from SHA-1 to SHA-512. For recipients whose certificates contain signatures on ECC (Elliptic Curve Cryptography), only the “KeyAgreeRecipientInfo” recipient type is available. This type uses a more sophisticated KEK (key encryption key) generation scheme: an ephemeral key is generated on the ECDH algorithm, and then a special “key derivation function” (KDF) is performed, based on the use of hashing algorithms. Here, the user can specify both the type of elliptic curve used (secp256r1, secp384r1 or secp521r1), as well as the type of hashing algorithm used in KDF.
With the “KEKRecipientInfo” type, everything is quite simple: the user sends the selected session key encryption algorithm to the function, as well as the buffer with the saved key for this algorithm. PKIjs in the future it remains only to use the previously transmitted data. The work with the “PasswordRecipientInfo” recipient type is slightly more complicated: the “key encryption key” is formed as a result of the PBKDF2 algorithm, and the session key is already encrypted with this data. Also, it is technically possible to use the HKDF algorithm, however, there is the same problem as with AES-CTR: there are no generally accepted OIDs for use in CMS Enveloped Data.
I will also say that at present PKIjs can generate types of cryptographic messages that are not supported, for example, in the latest releases of OpenSSL, as well as in Microsoft CryptoAPI (and CNG). For example, in OpenSSL there is no possibility (through a standard console application) to decrypt data using PBKDF2 + AES-KW, and in Microsoft CryptoAPI there is no support for the “dhSinglePass-stdDH-sha1kdf-scheme” and “dhSinglePass-stdDH-sha512kdf-scheme” schemes , as well as the recipient types KEKRecipientInfo and PasswordRecipientInfo.
A more detailed description of the encryption capabilities is provided in the README file located in the directories of encryption examples using a certificate , as well as using a password .
In conclusion, I will say that this library continues to grow, but with the help of Peculiar Ventures . Library features will only expand, stay tuned. I would be grateful for the constructive comments, as well as the description of projects implemented using PKIjs. For advice on working with the library you can contact me, its author directly.
Source: https://habr.com/ru/post/255565/
All Articles