バウンシー キャッスル (暗号化)

Bouncy Castle は、コンピュータ プログラムで暗号化を実装するために使用されるAPIのコレクションです。JavaとC# の両方のプログラミング言語用の API が含まれています。API は、オーストラリアの登録慈善団体であるLegion of the Bouncy Castle Inc. によってサポートされています。

Bouncy Castle はオーストラリア発祥であるため、米国からの暗号の輸出に関する米国の規制は適用されません。

Bouncy Castle は、2 人の同僚がサーバーサイドJava SEで働いていたときに転職するたびに暗号化ライブラリのセットを再発明しなければならないことにうんざりしたことから始まりました。開発者の 1 人は趣味でJava ME (当時は J2ME) 開発に携わっており、設計上の考慮事項として、ライブラリに J2ME 上のものも含めた最も広範囲の Java VM を含めることが挙げられました。この設計上の考慮事項が、Bouncy Castle のアーキテクチャにつながりました。^[7]

2000 年 5 月に設立されたこのプロジェクトは、当初 Java のみで書かれていましたが、2004 年に C# API が追加されました。元の Java API は、テスト コードを含めて約 27,000 行のコードで構成され、J2ME、JCE / JCAプロバイダー、基本的なX.509証明書生成のサポートを提供していました。これに対して、1.53 リリースは、テスト コードを含めて 390,640 行のコードで構成されています。元のリリースと同じ機能をサポートしており、より多くのアルゴリズムに加えて、PKCS #10、PKCS#12、CMS、S/MIME、OpenPGP、DTLS、TLS、OCSP、TSP、CMP、CRMF、DVCS、DANE、EST、属性証明書をサポートしています。C# API は約 145,000 行のコードで構成され、Java API の機能のほとんどをサポートしています。

プロジェクトの主な特性は次のとおりです。

• 標準準拠と適応性を重視します。
• 公開サポート機能には、問題追跡、開発者メーリング リスト、Wiki などがあり、すべて Web サイトで利用できます。
• Bouncy Castleのウェブサイトに記載されている関連APIのリソースに基づいて提供される商用サポート

2013年10月18日、オーストラリアのビクトリア州に、コア開発者らがプロジェクトの所有権を取得し、APIの継続的な開発をサポートするために、非営利団体のLegion of the Bouncy Castle Inc.が設立されました。この団体は、2013年11月7日にオーストラリア慈善団体および非営利団体委員会によって、教育の推進と地域社会への利益を目的とするオーストラリアの慈善団体として認定されました。 ^{[8]団体は、2013年11月29日に}消費者問題ビクトリア州によってその目的を支援するための資金調達を許可されました。

Bouncy Castle アーキテクチャは、基本的な暗号化機能をサポートする 2 つの主要コンポーネントで構成されています。これらは、「軽量」 API とJava Cryptography Extension (JCE) プロバイダーと呼ばれます。JCE プロバイダー上に構築されたその他のコンポーネントは、PGPサポート、S/MIMEなど の追加機能をサポートします。

低レベル、つまり「軽量」な API は、基礎となるすべての暗号化アルゴリズムを実装する API のセットです。API は、必要に応じて使用できるようにシンプルに設計されていますが、JCE プロバイダーの基本的な構成要素を提供します。その目的は、メモリが制限されたデバイス (JavaME) や、JCE ライブラリに簡単にアクセスできない場合 (アプレットでの配布など) に低レベル API を使用することです。軽量 API は単なる Java コードであるため、Java 仮想マシン (JVM) はコードの動作に制限を課しません。Bouncy Castle の歴史の初期には、JCE プロバイダーによる「強力な」暗号化の実行を妨げる管轄ポリシー ファイルによって制限されない強力な暗号化を開発する唯一の方法でした。

JCE 互換プロバイダは、低レベル API に基づいて構築されています。そのため、JCE プロバイダのソース コードは、低レベル API を使用して多くの「一般的な」暗号化の問題を実装する方法の例です。オープン ソース認証局EJBCAなど、多くのプロジェクトが JCE プロバイダを使用して構築されています。

C# および Java リリースには、 FIPS 140-2レベル 1 認定ストリームもあります。これらは、モジュールは通常のリリースと同様に設計されていますが、低レベル API がかなり異なっているという点で、通常のリリースとは異なります。これは主に、アルゴリズムの使用時に FIPS が要求する制御の適用をサポートするためです。Java API の JCE レベルの場合、プロバイダーは依然として、通常リリースの代替品としてほぼ機能します。最初の FIPS 認定リリースは 2016 年 11 月に提供され、最新の Java バージョンには認定番号 4616、最新の C# バージョンには認定番号 4416 が割り当てられました。

Androidオペレーティングシステムには、2014 年初頭の時点で、Bouncy Castle のカスタマイズされたバージョンが含まれています。^{[9]クラス名の競合により、Android}アプリケーションは Bouncy Castle の公式リリースをそのまま含めて使用することはできません。Spongy Castleと呼ばれるサードパーティ プロジェクトは、この問題を回避するためにライブラリの名前を変更したバージョンを配布しています。^[10]

当初は、 Spongy Castleの FIPS 140-2 バージョンも実行できると想定されていました。Android の DEX ファイル処理により、FIPS の目的上、プロバイダーはアプリケーションとは別にデバイスにインストールする必要があることが判明しました。Android 用の FIPS 140-2 リリースは現在Stripy Castleと呼ばれ、 org.stripycastleにパッケージ化されています。これは、Android バージョンの Bouncy Castle との競合、および Spongy Castle を使用していて FIPS 140-2 認定サービスを必要としない可能性のあるアプリケーションとの競合を回避するために必要でした。

• 暗号化ライブラリの比較

• 公式サイト