PKIベースのソリューションの人気は高まり続けています。ますます多くのサイトがHTTPSに切り替えられ、企業はユーザーとコンピューターの認証用のデジタル証明書を導入しています.S / MIMEは電子メール暗号化の価値を証明しており、フィッシングを防ぐためのメッセージソースを確認する方法としても機能しています。 しかし、これらのアプリケーションでの暗号化と認証は、適切なキー管理がなければ実質的に意味がありません。



証明機関（CA）または自己署名証明書からデジタル証明書を発行するたびに、秘密キーと公開キーのペアを生成する必要があります 。 ベストプラクティスによると、秘密キーは保護されている必要があります。 誰かが受け取った場合、証明書の種類に応じて、組織の証明書をアドレスバーに使用してフィッシングサイトを作成し、企業ネットワークで自分自身を認証し、あなたになりすまし、あなたに代わってアプリケーションまたはドキュメントに署名するか、暗号化されたメールを読むことができます。



多くの場合、秘密キーは従業員の個人ID（したがって、組織の個人データの一部）であるため、秘密キーを保護することは、生体認証情報を使用して指紋を保護することと同等です。 ハッカーに指紋を取得させないのですか？ 秘密鍵についても同じです。



この記事では、秘密鍵を保護および保存するためのオプションについて説明します。 後でわかるように、これらのオプションは証明書の種類とその使用方法によって若干異なる場合があります（たとえば、SSL / TLS証明書の推奨事項はエンドユーザー証明書の推奨事項と異なります）。

OSおよびブラウザの証明書/キーストア

例：Windows証明書ストア、Mac OSキーチェーン



一部のオペレーティングシステムとブラウザには、証明書またはキーストアがあります。 これらは、コンピューターのローカルに証明書の一部として秘密キーと公開キーのペアを保存するソフトウェアデータベースです。 このようなキーストレージは非常に人気があります：多くのアプリケーションはここでキーをすぐに自動的に検索し、毎回証明書ファイルを手動で指定する必要がないため、これは非常に便利なオプションです。



このオプションのもう1つの利点は、構成が非常に簡単なことです。 秘密キーのエクスポートを有効/無効にし、信頼できる保護（証明書を使用するたびにパスワードを入力）を有効にし、秘密キーがエクスポートされた場合はバックアップコピーを作成できます。 さらに、Windowsでプロファイルの移動を有効にすると、証明書がプロファイルに添付され、このプロファイルで別のコンピューターにログオンしたときに使用可能になります。



このオプションを選択する場合は、いくつかの側面を考慮する必要があります。 まず、秘密キーをエクスポート不可としてマークした場合でも、一部のユーティリティはこの保護をバイパスできます（つまり、エクスポートできないことは保証されません）。 さらに、誰かがあなたのアカウントで働いていて、強力な秘密キー保護（証明書を使用するときのパスワード）をオンにしなかった場合、彼らはあなたの証明書を使用できます。 最後に、秘密鍵がエクスポート可能としてマークされている場合、コンピューターの誰かがそれをエクスポートできます。 秘密鍵保護を有効にしている場合でも、エクスポート時にパスワードは要求されません。



最後に、ChromeとIEはWindows証明書ストアを使用しますが、Firefoxは独自の証明書ストア（Mozillaから）を持っています。 つまり、証明書をWindowsストアにインポートすると、ChromeとIEは自動的にそれを見つけますが、Firefoxはそれを見つけられません。

典型的なアプリケーション：

• デジタル署名されたアプリケーション（Adobe Acrobat、Microsoft Outlook、Officeなどは、Windows証明書ストア[カスタム]にアクセスします）。
• Microsoft IISサーバーは、Windows証明書ストア（コンピューターに共通）でSSL証明書も探しています。
• クライアント（ユーザーまたはコンピューター）の認証は、設定に応じて、ほとんどの場合Windows証明書ストアにアクセスします。
• Windowsでのコードの署名（アプリケーションとドライバー）。

.Pfxおよび.jksファイル（キーストア）

PKCS＃12ファイル（.pfxまたは.p12）および.jks *（Java Keytoolツールで作成）には、秘密鍵と公開鍵が含まれています。 OSやブラウザのローカルストレージとは異なり、これらのファイルはリモートサーバーを含むほぼどこにでも配置でき、常にパスワードで保護されます（つまり、秘密キーを使用するたびにパスワードを入力する必要があります）。 もう1つの魅力的な機能：これらは単なるファイルであるため、証明書を使用する必要がある複数のユーザーに簡単にコピーを送信できます。



リモートサーバーにファイルを保存する場合は、特にファイルへのアクセスを制限するよう注意してください。 誰かがアクセスを取得した場合、その証明書を使用できます。 同様に、これらのファイルの簡単なコピーと配布には特に注意する必要があります。 これは非常に便利ですが、攻撃者がキーストアへのアクセス権を取得した場合、簡単にコピーを作成できます。 コピーされたファイルを効率的に使用するには、秘密鍵のパスワードが必要です。 これは、大文字、数字、特殊文字を含む15文字以上の強力なパスワードを使用するもう1つの理由です。 このストレージオプションで考慮すべき点がもう1つあります。エンドユーザーは、ファイルの場所と、ファイルが正しく格納されているかどうかに関して、より多くの責任を負います。



暗号化機器またはWindowsキーストア（上記を参照）を使用できないが、（コンピューターにキーストアファイルを配置するだけでなく）セキュリティを高めたい場合は、このファイルを安全な場所にあるUSBフラッシュドライブに書き込むことができます。 もちろん、ここではある程度の利便性が失われるため、署名を頻繁に使用する必要がある場合は、アクセスを容易にするためにファイルをローカルに保存することをお勧めします。

典型的なアプリケーション：

• WindowsまたはJavaコードへの署名。
• FDA ESGおよびIRS IDESは、.pfxを使用して米国政府機関と安全に通信します。
• 一部のWebサーバー（Apache TomcatまたはJbossなど）。

*注：Java は最近 、デフォルトのキーストアタイプとしてJKSからPKCS＃12に移行しました。

暗号化トークンとスマートカード

先ほど触れたように、秘密鍵を別の機器に保存することでセキュリティを強化できます。 ただし、暗号化トークンまたはスマートカードと標準フラッシュドライブの使用には大きな違いがあります。 暗号化機器の場合、キーは機器自体で生成され、エクスポートされません。 秘密キーがデバイスから離れることはないため、部外者がアクセスして侵害することは困難です。



注：既に以前に生成された（つまり、トークン自体ではない）秘密キーをさらに保護する場合は、.pfxファイルをトークンにインポートしてから、元の.pfxを削除できます。



トークンを使用すると、証明書を使用するたびにパスワードを入力する必要があります。 これは、誰かがあなたのトークンを受け取っても、パスワードが必要であることを意味します。 キーをトークンに保存すると、複数のコピーを作成してエクスポート/インポートプロセスを実行しなくても、複数のコンピューターで同じ証明書を安全に使用できます。 暗号機器は 、一部の業界および政府の規制に必要なFIPSに準拠しています。



もちろん、選択する場合は、他にも考慮すべき考慮事項があります。 トークンを管理する追加の困難に加えて、証明書を使用するたびにパスワードを入力する必要があるため、このオプションは自動アセンブリでは機能しない場合があります。 また、秘密キーはエクスポートされないため（追加のセキュリティがないため）、証明書をバックアップする方法もありません。 最後に、一部のシナリオでは、このストレージオプションは単純に不可能です。 たとえば、特殊なデバイスがトークンまたはスマートカードをサポートしていない場合。 または、従業員がコンピューターに物理的にアクセスできないが、リモート端末から作業する状況。

典型的なアプリケーション：

原則として、OS /ブラウザーのストレージ用にリストされているすべてのユースケース（ドキュメントとコードの署名、クライアント認証、Windows IIS）は、適切なドライバーがある場合、暗号トークンまたはスマートカードをサポートします。 ただし、これは常に実用的ではありません（たとえば、Webサーバーやコードに署名するための自動ビルドシステムでは、署名を適用するたびにパスワードが必要になります）。



規制順守は、暗号トークンを使用する主な理由の1つです。

• CA / Browserフォーラムで推奨されているExtended Validation（EV）コードへの署名が必須です。
• CA Security Councilの最小要件に準拠した標準コード署名に推奨されます。 認証局は、証明書を発行するための主要なオプションとして暗号化機器を推奨する必要があります。 暗号化機器が発行されていない場合、クライアントは、一部の取り外し可能な機器（署名後に削除される）に秘密鍵を保持することに同意する必要があります。
• Adobe承認済み信頼リスト（AATL）の要件に従って、デジタル署名およびAdobeプログラムでの信頼状態の取得に必要です。
• FDAのCFR 21パート11や個々の国のデジタル署名要件などの業界ルールは、所有者のみが所有する秘密キーを示していることがよくあります。 暗号機器のストレージはこれらの要件を満たしています。

ハードウェア暗号化モジュール（HSM）

HSMは別のハードウェアキーストレージソリューションです。特に、個々のトークンに依存したくない場合や、負担が大きすぎる場合はそうです。 トークンは手動入力または個々のアプリケーション（たとえば、少量のドキュメントまたはコードへの署名、VPNまたはその他のネットワークでの認証）に重点を置いていますが、HSMはAPIを提供し、自動化されたワークフローと自動化されたアセンブリをサポートします。 また、FIPS要件に準拠しており、通常はトークンよりも高い評価を提供します。



従来、HSMはローカルの物理デバイスであり、基本的な要件とSLAを管理および提供するために適格なリソースが必要です。 HSMサービスは高価で時間がかかる場合があり、過去にはこの技術の普及を妨げていました。 幸いなことに、近年、オンプレミスメンテナンスを必要とせずにオンプレミスHSMの多くの利点を提供するHSMクラウドモジュールが登場しました。



たとえば、Microsoft Azureクラウドの使い慣れたKey Vaultサービスは、MicrosoftのクラウドHSMに暗号化キーを保存します。 独自のHSMを購入して管理する余裕のない小規模な組織がある場合、これはGlobalSignなどの公的認証機関と統合する優れたソリューションです。



ドキュメントに署名するオプションを検討している場合、最近、新しいデジタル署名サービスを開始しました。これは、秘密鍵にもHSMクラウドストレージを使用します。 新しいサービスがすべての従業員の個々の署名をサポートすることは注目に値します。 これまで、ほとんどのHSM署名ソリューションは、部門または組織レベル（簿記、マーケティング、財務など）の識別子のみをサポートし、個人（ジョンドーなど）はサポートしていませんでした。 したがって、個々の従業員のレベルで作業するには、組織はトークンインフラストラクチャを展開する必要がありました。これは、上記のように負担が大きい場合があります。 この新しいサービスにより、個々の従業員のデジタル署名が実装され、HSMを個別に管理する必要がなくなります（従業員がトークンを失うリスクもなくなります）。

典型的なアプリケーション：

• 大量の文書またはコードの署名。
• SSL（サーバー構成に依存）。
• 独自のCA（ルートCA、下位CA、RFC 3161タイムスタンプサーバー）をオフラインまたはオンラインで運用するためのCAのインフラストラクチャ（通常、ルートCAはオフラインで動作します）。

将来の鍵保管方法

長年使用されてきた主なオプションを検討しました。 しかし、キーストレージを含む情報セキュリティの世界では、IoTの影響を受けないものはないようであるため、新しいオプションが開発されています。



認証と安全なデータ交換を必要とするネットワークに接続するデバイスが増えるにつれて、多くの開発者とメーカーがPKIベースのソリューションに注目しています。 次に、これは秘密鍵を保護するための新しい考慮事項、要件、および技術につながります。 以下は、この分野で見られる2つの傾向です。

トラステッドプラットフォームモジュール（TPM）

TPMは、それ自体は新しいものではありませんが、秘密鍵の保護にますます使用されています。 トラステッドプラットフォームモジュールを使用して、ルートキーを格納（または転送）し、アプリケーションによって作成された追加キーを保護できます。 アプリケーションキーはTPMなしでは使用できないため、ラップトップ、サーバー、IoTデバイスメーカーなどのエンドポイントにとって非常に便利な認証方法です。 多くのラップトップにはすでにTPMが搭載されていますが、これまでのところ、このテクノロジーは企業部門ではあまり広く使用されていません。 ただし、IoTの世界では、デバイスをハードウェアの信頼のルートとして安全に識別するためによく使用されます 。



IoTは、多くの匿名で対話するデバイスが、ハッカーがメッセージを傍受したり、デバイスになりすますことを容易にする問題を引き起こしました。 生産段階でTPMモジュールが導入され、暗号化キーを保護するため、デバイスを確実に識別できます。



実動中に、秘密鍵と公開鍵のペアが生成されます。 公開鍵は認証局に送信され、デジタル証明書に署名して発行されます。 秘密鍵がデバイスから離れることはありません。 チップに保存され、エクスポート/コピー/破壊することはできません。 これで、証明書はデバイスのパスポートになり、保護された秘密キーが信頼のハードウェアルートを形成します。



インフィニオンと密接に連携して、PKIベースのデバイス識別とTPMベースの信頼の根を組み合わせたIoTソリューションを開発しています。 詳細については、概念実証「InfineonのGlobalSignおよびOPTIGA TPM証明書クラウドサービスによる安全な認証と機器管理」をご覧ください。

物理的に複製不可能な関数（PUF）

Physically Nonclonable Feature Technology（PUF）は、キー保護におけるパラダイムシフトです。 キーを（物理的な攻撃の確率で）保存する代わりに、特定のチップのSRAM静的メモリの固有の物理プロパティから生成され、電源がオンになったときにのみ存在します。 つまり、秘密キーの信頼性の高いストレージの代わりに、同じキーが（デバイスがクラッシュするまで）オンデマンドで何度も復元されます。 このキーは、世代がチップのシリコン構造に固有の制御不能な乱れを使用するため、一意であることが保証されています。



Trusted Execution Environment（TEE）と組み合わせたPUFテクノロジーは、低コストで統合しやすく、極めて安全なキー保護のための魅力的なソリューションです。 PUFとPKIは、包括的な識別ソリューションを構成します。



パートナーのIntrinsic IDは、SRAM PUFに基づいたこのようなキー準備システムを開発しました。このシステムは、偽造やコピーから保護されるハードウェアで保護された一意のデバイス識別子を生成します。 認定サービスを使用して、これらの識別子をデジタルIDに変換し、PKI機能を追加します。 したがって、各デバイスには、オフ状態のデバイスに保存されていない一意のキー保護キーペアが割り当てられますが、デバイスは要求に応じてこのキーを再作成できます。 これにより、電源がオフのデバイスに対する攻撃から保護されます。



共同識別ソリューションの詳細

IoTデバイスについては、最近のウェビナー「永続的なSRAM PUF証明書デバイス識別子」をご覧ください。

お城への（秘密の）鍵をなくさないでください！

秘密鍵ストレージは黒魔術であってはなりません。 最終的に、正しいオプションは、誰が何のために証明書を使用するか、どの標準に従う必要があるか、価格、現在の環境、および内部リソースによって異なります。 この記事があなたの決定に役立つことを願っています。



_______________________________________________________

---

プロモーショングローバルサイン：ワイルドカードSSL +ギフトとして1年

1つの証明書ですべてのサブドメインを保護してください！



ワイルドカードSSL証明書を2年間購入すると、最大3万ルーブル節約できます！

プロモーションコード：WC001HRFR



このプロモーションは、2018年6月15日まで、 GlobalSignブログサブスクライバーに対して有効です。



GlobalSignマネージャーから電話で追加情報を入手できます：+7（499）678 2210またはWebサイトのフォームにプロモーションコードを記入してください 。