したがって、PKIjsの現在の主な機能：
- Web Cryptography APIの完全サポート。
- iPhone（Safariを使用）とAndroidアプリケーション（Google Chrome）の両方で使用する能力が制限されています。
- 例の数が増えました。 特に、PKIjsを使用してPDFファイルの署名をチェックし、S / MIMEの署名をチェックする例が追加されました。
- Web Cryptography APIのすべての署名アルゴリズムを使用：
- RSASSA-PKCS1-v1_5（PKCS＃1 v1.5）;
- RSA-PSS（PKCS＃1 v2）;
- ECDSA（ECC署名、楕円曲線暗号化）;
- 純粋なJavaScriptでの「証明書チェーン検証エンジン」（純粋な証明書チェーン検証）の最初の実装であり、メインのNISTテストに合格します。
- 純粋なJavaScriptの「オープンソース」のCMS（暗号メッセージ構文）の形式でデータに署名および暗号化する「スイートB」の最初でこれまでの唯一の実装。
- ECDSAを使用したCMS署名。
- はかない静的ECDHスキームを使用した暗号化。
- AES-CBCおよびAES-GCMを使用。
- ハッシュアルゴリズムの拡張リストの使用：SHA-1からSHA-512。
- AESシリーズアルゴリズムを使用して、パスワードの使用に基づいて暗号化されたメッセージを作成する機能。
まず、署名の実装。 使用するすべてのアルゴリズムを既にリストしましたが、PKIjsを使用すると、これらすべてのアルゴリズムを使用するさまざまなタイプの暗号化オブジェクトを作成できることに注意してください。
- X.509証明書。
- X.509 CRL（証明書失効リスト）;
- PKCS＃10形式の証明書の作成の要求。
- OCSPリクエスト;
- OCSP応答;
- TSPリクエスト;
- TSP応答;
- CMS署名データ;
これらすべてのタイプの暗号オブジェクトには、以前にエンコードされたオブジェクトの内部構造を取得したり、オブジェクトの新しい構造を作成したり、内部データに署名したり、既存の署名を検証したりできる便利な「ヘルパー」があります。 また、タイプごとに、可能なすべての署名アルゴリズムを使用した個別の使用例があります。
次に、暗号化の実装について説明します。 Web Cryptography APIの作成者は、暗号化アルゴリズムに関する最新情報に基づいて標準を作成しました。 これを考えると、Web Cryptography APIは暗号化の世界から時代遅れのすべてを遮断しようとしたと言えます。 PKIjsはWeb暗号化APIのみに基づいているため、PKIjsは暗号化データ（CMS Enveloped Data）を生成するための最新のアルゴリズムを実装し、誰もが知っている古いアルゴリズムを遮断する必要がありました。
PKIjsは、暗号化されたCMSメッセージのすべてのタイプの受信者と連携する機能を実装します。
- KeyTransRecipientInfo（非対称アルゴリズムを使用したセッションキー暗号化）;
- KeyAgreeRecipientInfo（「共有シークレット」に基づくセッションキー暗号化）;
- KEKRecipientInfo（既知の「キー暗号化キー」値に基づくセッションキー暗号化）;
- PasswordRecipientInfo（指定されたパスワードから派生したデータに基づくセッションキー暗号化）;
暗号化されたCMSメッセージのすべてのタイプの受信者に共通：PKIjsでは、メインデータ暗号化アルゴリズムとして、AES-CBCとAES-GCMの2つのアルゴリズムを使用できます。 AES-CTRを使用することも技術的には可能ですが、このアルゴリズムには、CMSメッセージで使用できる一般的に受け入れられているOIDとアルゴリズムパラメータはありません。
最初に、暗号化されたメッセージの受信者の主な種類、「KeyTransRecipientInfo」と「KeyAgreeRecipientInfo」について説明します。 「KeyTransRecipientInfo」タイプは現在、RSAアルゴリズム（RSASSA-PKCS1-v1_5およびRSA-PSS）で署名されたX.509証明書がある受信者に対してのみ可能です。 KeyTransRecipientInfoタイプの受信者に暗号化を実装する場合、RSA-OAEP非対称暗号化アルゴリズム（RSASSA-OAEP）が使用されます。 RSA-OAEPの場合、MGF1のみが厳密に適用されますが、SHA-1からSHA-512までのハッシュアルゴリズムを指定することは可能です。 証明書にECC署名（楕円曲線暗号化）が含まれる受信者の場合、受信者タイプ「KeyAgreeRecipientInfo」のみが利用可能です。 このタイプでは、より複雑なKEK（キー暗号化キー）生成スキームが使用されます。ECDHアルゴリズムを使用して一時キーが生成され、その後、ハッシュアルゴリズムの使用に基づく特別な「キー派生関数」（KDF）が実行されます。 ここで、ユーザーは、使用される楕円曲線のタイプ（secp256r1、secp384r1またはsecp521r1）と、KDFで使用されるハッシュアルゴリズムのタイプの両方を指定できます。
KEKRecipientInfoタイプでは、すべてが非常に簡単です。ユーザーは、選択されたセッションキー暗号化アルゴリズムと、このアルゴリズム用に保存されたキーを持つバッファーを関数に渡します。 将来のPKIjsでは、以前に送信されたデータのみを使用します。 受信者タイプ「PasswordRecipientInfo」はもう少し複雑です。「キー暗号化キー」はPBKDF2アルゴリズムの結果として生成され、セッションキーはすでにこのデータで暗号化されています。 HKDFアルゴリズムを使用することも技術的には可能ですが、AES-CTRと同じ問題があります。CMSエンベロープデータで使用するために一般に受け入れられているOIDはありません。
また、現在、PKIjsは、たとえばOpenSSLの最新リリースやMicrosoft CryptoAPI（およびCNG）でサポートされていない種類の暗号化メッセージを生成できます。 たとえば、OpenSSLでは（標準コンソールアプリケーションを介して）PBKDF2 + AES-KWを使用するデータを解読する方法はなく、Microsoft CryptoAPIはdhSinglePass-stdDH-sha1kdf-schemeおよびdhSinglePass-stdDH-sha512kdf-schemeスキームをサポートしません、受信者タイプ「KEKRecipientInfo」および「PasswordRecipientInfo」。
暗号化機能のより詳細な説明は暗号化例のカタログにあるREADMEファイルで証明書とパスワードで与えられます 。
結論として、このライブラリはPeculiar Venturesの助けを借りて開発を続けています。 ライブラリの機能は拡張されるだけで、今後もご期待ください。 建設的なコメントと、PKIjsを使用して完了したプロジェクトの説明に感謝します。 ライブラリの操作に関するアドバイスについては、その著者である私に直接お問い合わせください。