コード署名とデジタル証明書の使用は、現代のテクノロジーの世界における信頼の概念の基礎です。
具体的には、プログラムの開発者の身元とその作成元を検証するために使用されるコード署名です。多くの X.509 証明書と同様、コード署名証明書には標準形式と拡張検証 (EV) 形式があります。
プログラムにコード署名することで、開発者はデジタル証明書を添付するだけです。コード署名証明書は、他のタイプのデジタル証明書で使用されるのと同じテクノロジーである公開キー暗号化を使用します。このアプローチは、モバイルからデスクトップまで、さまざまな種類のプラットフォームのオペレーティング システムで使用できます。Microsoft の Windows、Apple の Mac OS X、Linux、さらには iOS や Android 用のツールも見つかります。IoT デバイスにも含まれていることがあります。これらの証明書をプログラムのソース コードに埋め込むことは、ソフトウェア開発におけるセキュリティと信頼の重要な側面です。
コード署名を実装する方法
これを実現するには、一意の秘密キーが必要です。秘密キーは、暗号化/復号化ハンドシェイクが簡単に破られないように適切にハッシュ化されています。公開キー暗号化では、公開キーと秘密キーの組み合わせがプロセスの中心となり、アクセスせずに通信できるようになります。
公開キー基盤 (PKI) を使用して新しいキー ペアが生成された後、公開キーは認証局 (CA) に送信され、CA は開発者の ID を検証し、独自の公開キーをコード署名証明書に添付します。証明書とコードは、証明書を要求した元の開発者に返送されます。
開発者はコード署名証明書と暗号化キーのペアを取得したので、ソフトウェアのコードを暗号化して署名する前にハッシュする必要があります。ハッシュとは、ハッシュ関数を使用してコードを任意の固定値に変換するプログラムです。ダイジェストと呼ばれるハッシュの出力は、秘密キーで暗号化されます。次に、開発者はこのダイジェストをコード署名証明書およびハッシュ関数と組み合わせて署名ブロックと呼ばれるものを作成します。これは基本的に上記のすべての項目をソフトウェアに簡単に挿入できるコードに結合します。
保全の重要性
コード署名に関する最大の問題は、証明書に関連付けられた秘密コード署名キーを保護することです。1 つのキーが侵害されると、証明書の信頼性と価値が失われ、署名したソフトウェアが危険にさらされます。
多くの組織は、秘密キーのセキュリティを強化するために、セキュリティ ボールトとハードウェア セキュリティ モジュール (HSM) を使用して組織を保護しています。他の組織では、Certificate Manager を使用して、すべてのコード署名証明書のライフサイクル管理を自動化し、安全に管理しています。この一例は、Sectigo 証明書マネージャーです。証明書マネージャーを使用すると、秘密キーやその他の暗号資産の整合性を促進するのに大いに役立ちます。
コード署名によって何が防止されるのでしょうか?
簡単に言うと、コード署名は、無害なファイルや Windows アップデートなどのイベントを装って、マルウェアやその他の悪意のあるコードがエンド ユーザーのシステムに導入されるのを防ぎます。これは、ダウンロードされているファイルが実際に発信者からのものであり、悪意のある行為者からのものではないことをユーザーが検証できるようにすることで実現されます。これにより、システム内の信頼の概念が強化され、開発者はソフトウェアをダウンロードするエンド ユーザーに対して、ソースが信頼でき、安全であることを保証できるようになります。
EV コード署名証明書は追加のセキュリティ保証を提供します。FIPS140-2 以上に準拠した高保証ハードウェアにキーを保存する必要があります。この要件を満たし、PIN コードによる別の保護層を追加する USB トークンがあります。あるいは、組織のハードウェア セキュリティ モジュール (HSM) にキーを保存することもできます。
ジョージア工科大学のサイバー フォレンジック イノベーション ラボの調査によると、拡張検証 (EV) TLS/SSL 証明書の発行と使用により、フィッシング攻撃や悪用に対する保護が 99.99% の確率で提供されます。
鍵を保護する簡単な方法
コード署名キーを保護するには、次のようなさまざまな方法があります。
テストキーとリリース署名キーを分離する
テスト環境は乱雑で混雑していますが、テスト署名キーは内部にあるため、通常、リリース署名キーほど厳重に保護する必要はありません。実際、多くの組織は、この理由から、テスト環境で自己署名証明書または信頼できない認証局を使用しています。テスト署名キーとリリース署名キーを分離すると、開発者が開発段階で 1 つのコード署名キーを使用し、それを使用してソフトウェアをリリースすることができなくなります。ただし、個別のテスト キーとリリース キーを使用するには、テスト インストーラーが顧客にプッシュされないように明確にマークする必要があります。
取り消しを真剣に受け止めてください
失効証明書は、コード署名キーを追跡する上で最も重要な部分の 1 つです。コード署名プロセス中に脆弱性が発見された場合、または秘密キーが公開された場合、システムの信頼性を適切に確保するために、それらに関連付けられたキーと証明書を取り消して再発行する必要があります。
時間はあなたの友達です
コード署名証明書は、他のデジタル証明書と同様に有効期限が切れます。これは、その証明書で署名された情報が無効であることを意味するのではなく、システムが比較のためにコード署名をチェックするときに、有効期限が切れていることを認識し、エンド ユーザーにエラー メッセージを表示することを意味します。タイムスタンプが期限切れになるたびに発生するこれらのアラートは回避できますが、ブランドに対する顧客の評判と信頼が損なわれます。これらの有効期限は、証明書を継続的に更新するという規律を強制し、リリースされたコード内の証明書が最新の暗号化手法を使用してハッシュされ、暗号化の脆弱性によって侵害されていないことを保証します。
コード署名のベスト プラクティス
コード署名によって、ソフトウェアが誤用、改ざん、悪意のある意図から完全に免れるわけではありません。秘密キーを処理するプロセスには人間の要素が大きく関与します。コード署名は、共通の目標を達成し、中断なくキーを保護するために、セキュリティ チームと開発チームが協力して責任を負う必要があります。
業界標準のベスト プラクティスに従うことで、このアプローチを可能な限り効果的にすることができます。Sectigo が推奨するコード署名のベスト プラクティス トップ 10 を以下に示します。
1. コード署名証明書でコードを保護する
最も重要な推奨事項は、可能な限りコード署名証明書を使用することです。これらの証明書は、コードの出所と信頼性をエンド ユーザーに証明し、個人のセキュリティに対する顧客の信頼を高めます。コードに適切に署名することで、信頼できる公的認証局によって管理される信頼をアプリケーションまたはプログラムに組み込むことができます。セキュリティを強化するために、EV コード署名証明書を使用できます。
2. 悪い習慣を身につけないようにする
システム内で証明書を適切に使用することは重要ですが、証明書を適切に維持および使用するための動作を強制しなければ、何をしても無駄になります。デジタル証明書の使用と重要性を理解する文化を構築することによってのみ、組織全体を改善することができます。
3. 秘密鍵へのアクセスを最小限に抑える
優秀な IT プロフェッショナルであれば、秘密キーや基礎となるルート証明書へのアクセスの制限など、できる限り多くのアクセス制御を行うでしょう。組織の秘密キーへのアクセスを許可する人はごく少数でなければなりません。また、それらの人にはアクセスが必要な明確な理由がある必要があります。組織内でロールベースのアクセス (rbac) ポリシーを確立すると、危険にさらされる可能性を制限できます。
4. 暗号化ハードウェアで秘密鍵を保護する
暗号化ハードウェアを使用すると、最新の暗号化アルゴリズムで秘密キーを保護できます。このタイプのハードウェアは、少なくとも FIPS 140 レベル 2 の認定を受ける必要があります。ハードウェア セキュリティ モジュール (HSM) などの製品は、秘密キーが悪者の手に渡らないように保護します。
5. コードにタイムスタンプを付ける
コードにタイムスタンプを付けると、コードが書き込まれた証明書と比較して、そのコードがいつ書かれたかを知ることができます。これにより、証明書の有効期限が切れたり取り消されたりしたときに、その証明書が正規のものであることを再確認できます。テクノロジーと暗号化された脅威が進化するにつれて、現在の保護が弱体化したり、完全に破壊されたりする可能性があるため、これは理解しておくべき重要な関係です。
6. テスト署名とリリース署名の違い
上で述べたように、テスト署名とリリース署名キー/証明書の違いを区別して理解することが重要です。テスト署名証明書と鍵には、プライベートな内部テスト CA によって自己署名できるため、それほどセキュリティは必要ありません。また、リリース署名された製品のルート証明書と連結する必要があり、ベスト プラクティスには、リリース署名とプレリリース署名用にまったく異なるコード署名インフラストラクチャを設定することが含まれます。これにより、テスト環境と運用コードに対して適切なアクセス制御を設定できるようになります。
7. 認証コード
コード署名はコードが安全であることを具体的に保証するものではなく、誰がコードを書いたかを明らかにするだけです。したがって、コードを誠意を持って一般に公開するには、コードを完全に認証する必要があります。こうすることで、顧客に損害を与えたり、評判を傷つけたりする可能性のある、誤ったコードや悪意のあるコードを誤って広めることを防ぐことができます。後で何らかの調査やインシデント対応が必要になった場合に備えて、すべての認定されたコード署名アクティビティを記録する必要があります。
8. ウイルススキャンコード
コードが変更されていないことを確認することに加えて、ウイルスやその他の悪意のあるコードをスキャンすることも重要です。悪意のあるコードは、外部プロジェクトから既存のコードを再利用またはインポートする開発者によって誤って挿入されることがよくあります。コードがリリースされる前にバグを見つけて変更するのがはるかに簡単です。
9. キーの再利用を制限する
コード署名のために秘密キーを複数回再利用すると、より大きなリスクにさらされます。キーが侵害された場合、そのキーでスタンプされたその日付までのコード署名はすべて無効になり、新しいコード署名証明書で更新する必要があります。さまざまなキーと証明書を循環する習慣を維持すると、リスクを分散し、証明書の再発行の労力と影響を軽減できます。
10. 侵害された証明書の取り消し
失効は、コードを安全に保つ上で最も重要なタスクの 1 つです。認証局は失効を誰よりも真剣に受け止めているため、コードにタイムスタンプを付けるなどのベスト プラクティスをお勧めします。
ただし、侵害されたコード、キー、または証明書を認証局に報告し、認証局が適切な措置を取れるようにするのは開発組織の責任です。何らかの問題が発生した場合、CA はコード署名証明書を取り消すように要求します。コードにタイムスタンプを付けると、イベントより後の失効日を持つコードのみが影響を受けます。