Autosar の自己署名証明書と CA 証明書

1. 安全な送信

1. 枠組み

2. 送信のセキュリティをどのように達成するか?

「暗号化 + 署名 + 証明書」は本質的に、非安全なチャネルで安全なデータ送信を実現するためのソリューションです。

• 1. 暗号化 - 盗聴防止: 平文を暗号文に変換します。暗号文を平文に復号化できるのは必要な受信者だけです。暗号文が攻撃者によって盗まれた場合でも、データの内容は理解できません。

• 2. 整合性の検証 - 改ざんの防止:元のデータの概要を計算し、データと概要を通信相手に配信します。また、受信機は、データを受信した後、そのダイジェストを計算し、受け付けたダイジェストと一致するかどうかを比較することで、受信データが改ざんされているかどうかを判断する。
  ただし、受信したダイジェストも改ざんされる可能性があるため、より安全な方法が必要です。デジタル署名 (ダイジェストの暗号化はデジタル署名です)。

• 3. データ ソースの認証 - マスカレードの防止: デジタル署名はデータの整合性を検証すると同時に、データ ソースを認証してマスカレードを防ぐことができます。

3. 対称暗号化と非対称暗号化の違いは何ですか?

• 1. 鍵管理：対称暗号アルゴリズムでは通信相手に鍵を送信する必要があり、鍵漏洩のリスクがあるが、非対称暗号アルゴリズムでは公開鍵が公開され、秘密鍵は秘密に保たれるため、秘密キーの送信を防止します。

• 2. 鍵機能: 公開鍵で暗号化されたデータは秘密鍵でのみ復号化できます。逆に、秘密鍵で暗号化されたデータは公開鍵でのみ復号化できます (注: 公開鍵が公開されている場合、公開鍵は公開されているため、公開鍵で暗号化されたデータは公開鍵では復号化できません)。復号化すると、暗号化セキュリティが失われます);

• 3. 計算性能: 非対称暗号アルゴリズムは計算効率が低いため、実際には 2 つのアルゴリズムを組み合わせた複合アルゴリズムがよく使用されます。まず、非対称暗号を使用して対称鍵を送信するための安全なチャネルを確立し、次にその鍵を使用します。対称暗号化。

• 4. 認証機能：非対称暗号アルゴリズムでは、一方のみが秘密鍵を保持し、認証と否認防止機能を備えます（この機能はセクション 3 のデジタル署名アルゴリズムに適用されます）。

HTTPSプロトコルでは、性能面を考慮して「対称暗号化」と「非対称暗号化」を組み合わせた「ハイブリッド暗号化」方式が採用されており、通信確立時に「セッションキー」のネゴシエーションに非対称暗号化を使用し、「セッションキー」に基づいて対称暗号化通信が行われます。通信プロセス中のキー。

4. 擬似乱数と真性乱数

乱数はコンピュータ セキュリティの分野で非常に重要なポイントであり、多くのシナリオで、キーの生成、ファイル名、sessionId/orderId/token などのランダム イベントを生成するために乱数が必要になります。最新の乱数生成モデルは、1946 年にフォン ノイマンによって設計された乱数モデルを依然として使用しています。

• 1.「シード」として任意の数値を入力し、乱数アルゴリズムを通じて乱数を取得します。
• 2. 生成された乱数を新しいシードとして使用し、次のラウンドの計算に代入します。
• 3. ステップ 1 と 2 を繰り返して、統計的に有意な複数の乱数を生成します。

ただし、このモデルによって生成される乱数は完全にランダムではありません。サンプリング範囲が十分に大きい限り、ランダムな結果は必ずサイクルに該当します。そのため、このモデルによって生成された乱数は「疑似乱数」としか呼ばれることができません。ランダムな結果がサイクルに該当するサイクルは次のようになります。 「ランダムサイクル」と呼ばれます。

実際の乱数を取得するには、ハードウェア レベルのサポートが必要です。

• 1999 年にインテルは、世界初の真の乱数発生器を i810 チップセットに統合しました。その解決策は、回路の熱ノイズ (分子の不規則な動き) をデータ ソースとして使用することです。欠点は、効率が低すぎることです。現在のコンピュータで使用される乱数は、依然としてソフトウェアによって実装された擬似乱数です。
• ソフトウェアを真にランダムにすることはできませんが、ジェネレーターのランダム性を向上させることはできます。たとえば、より強力なランダム アルゴリズム (Java#SecurityRandom) を使用し、より複雑なシード (システム時間、マウスの位置、ネットワーク速度、ハードディスクの読み取りおよび書き込み速度) を使用し、乱数の値の範囲を拡大し、複数のランダム アルゴリズムを組み合わせます。 。

5. デジタル署名 - 整合性の検証とデータ ソースの認証

デジタル署名 (デジタル指紋とも呼ばれます) は、メッセージ ダイジェスト アルゴリズムと非対称暗号化アルゴリズムを組み合わせたもので、データの整合性を検証し、データのソースを認証できます。

デジタル署名アルゴリズムのモデルは、次の 2 つの主要なフェーズに分かれています。

• 1. 署名: まずデータの [概要] を計算し、次に秘密キーを使用して [概要] を暗号化して [署名] を生成し、[データ + 署名] を受信者に送信します。
• 2. 検証：最初に同じダイジェストアルゴリズムを使用して受信データの[ダイジェスト]を計算し、次に事前に取得した公開キーを使用して[署名]を復号化し、[復号化された署名ダイジェスト]と[計算された署名ダイジェスト]を比較します。ダイジェスト] は一貫しています。それらが一致していれば、データが改ざんされていないことを意味します。
  

「公開鍵」を使用してデータを暗号化し、「秘密鍵」を使用して復号化する場合は「暗号化」になります。そうでない場合は、「秘密鍵」を使用してデータを暗号化し、「公開鍵」を使用して復号化します。それが「署名」です。

• 誰もが公開鍵を持っているため、誰もが公開鍵を使用してデータを復号化できるため、「署名」によってデータの安全性が保証されるわけではありません。
• ただし、「署名」を使用すると、メッセージの正確性と否認防止を保証できます。公開鍵と秘密鍵の間には 1 対 1 の対応関係があるため、公開鍵で暗号文を復号できる場合、その暗号文は秘密鍵の所有者からのものでなければならないことを意味します。

6. ダイジェスト アルゴリズムを使用したデジタル署名で整合性を検証できるのはなぜですか?

検証の整合性は主にメッセージ ダイジェスト アルゴリズムの特性に依存します。ダイジェスト アルゴリズムの原理は、特定の操作ルールに従って元のデータ内の情報を抽出することです。抽出された情報は、元のデータのメッセージ ダイジェスト (別名メッセージ ダイジェスト) です。データの指紋。

• データに対して一方向ハッシュ関数を実行して、データの概要である固定長のハッシュ値を生成します。
• 有名なダイジェスト アルゴリズムには、MD5 アルゴリズムや SHA シリーズ アルゴリズムなどがあります。

ダイジェスト アルゴリズムには次の特徴があります。

一貫性: 同じデータの複数の計算の要約は同じであり、異なるデータの要約 (衝突が考慮されていない場合) は異なります; 非可逆性: 元のデータの要約のみを前方に抽出でき、元のデータは抽出できませ
ん要約から逆にされる;
効率: 要約の生成プロセスは効率的かつ高速です。

ダイジェスト アルゴリズムのモデルは、次の 2 つの主要なステップに分かれています。

サマリーの生成: 最初にデータの [サマリー] を計算し、次に [データ + サマリー] を受信者に送信します; サマリーを
検証: 同じサマリー アルゴリズムを使用して受信データの [サマリー] を計算し、[受信したサマリー] を比較します[計算された概要] と一致します。それらが一致していれば、データは完成です。

ダイジェスト アルゴリズムに依存するだけでは、データの整合性を厳密に検証できません。非セキュアチャネルではデータと概要の両方が改ざんされるリスクがあり、攻撃者がデータを改ざんする際に概要も改ざんする可能性があるためです。したがって、ダイジェストアルゴリズムは暗号化アルゴリズムと連携して完全性を厳密に検証する必要があります。

メッセージ ダイジェストの利点:

• たとえば、ファイルをダウンロードすると、データ ソースからファイルの MD5 が提供されます。ファイルをダウンロードした後、ファイルの MD5 をローカルで計算し、データ ソースから提供される MD5 と比較し、それらが同じであればファイルは完成です。しかし、メッセージダイジェストを単独で利用する場合、データソースから取得したMD5が途中で改ざんされていない保証がないため、データが改ざんされていないことを保証することができません。
• ダイジェスト アルゴリズムは、暗号化アルゴリズムに比べて比較的高速です。

7. デジタル署名でデータ ソースを認証できるのはなぜですか?

これは、署名に送信者の個人情報（秘密鍵）が組み込まれており、他人には偽造できないデジタル署名（暗号化文字列）を生成できるのは「正当な送信者」だけであり、このデジタル署名がデータの真の出所を証明するためです。 。

• 受信者が送信者の公開情報（公開鍵）を「法的手段」で取得し、デジタル署名の検証に成功すると、そのデータは「合法的な受信者」からのものであることになります。
  また、署名時には送信者の個人情報が導入され、検証時には送信者の公開情報が使用される点は、まさに「非対称暗号化」の特徴と一致しています。
  署名中に導入された秘密情報はまさに秘密鍵であるため、検証中に使用される公開情報は公式の公開鍵です。

8. 秘密キーを使用して最初に元のデータに署名し、その後その署名をダイジェストすることはできますか?

いいえ、主な理由は次の 2 つです。

• 1. 実現可能性: 受信者はダイジェストを通じてデータの整合性を検証する必要がありますが、受信者はデータに署名できないため、データ ダイジェストの一貫性を検証できません。
• 2. 時間効率：元データの署名（暗号化）に時間がかかりすぎるが、ダイジェストアルゴリズム自体が圧縮マップであるため、署名にかかる時間を短縮できる。

9. 受信者は送信者の公開キーを安全に取得するにはどうすればよいですか? - デジタル証明書

デジタル証明書とは何ですか?

• デジタル署名とデジタル証明書は常にペアで表示され、この 2 つを分離することはできません。デジタル署名は主にデータの整合性の検証とデータ ソースの認証に使用され、デジタル証明書は主に公開キーを安全に発行するために使用されます。
• デジタル証明書には主に、ユーザーの情報、ユーザーの公開キー、証明書の実体情報に対する CA の署名の 3 つの部分が含まれています。

デジタル証明書モデルは主に 2 つのステップに分かれています。

• 1. 証明書の発行:

(1) 申請者は、署名アルゴリズム、公開鍵、有効期限などの情報を CA 組織に送信します (
2) CA 組織は、申請者の身元を確認した後、申請者から送信された情報を実体化し、要約を計算する;
(3) CA 組織は独自の秘密キーを使用して要約を暗号化し、証明書署名 (証明書署名) を生成します; (4)
CA 組織は証明書署名をデジタル証明書に追加して、完全なデジタル証明書を形成します。

• 2. 検証証明書

(1) 検証者は、同じダイジェスト アルゴリズムを使用してデジタル証明書エンティティのダイジェストを計算します、
(2) CA 機関の公開キー (CA の公開キー情報はブラウザとオペレーティング システムに統合されています) を使用して復号化します。デジタル証明書の署名
(3) 比較 復号化されたデータが計算されたダイジェストと一致するかどうか、一致する場合、それは信頼できる証明書です。

(1) CAルート証明書の生成

ルート証明書はオペレーティング システムにプリインストールされており、ルート証明書は正しいものである必要があると考えられます。

ステップ：

• 1. 当局は RSA などのアルゴリズムを使用して、公開鍵 K1 と秘密鍵 K2 のペアを生成します。
• 2. 公開鍵 K1、証明書発行局、有効期間などの情報が元の証明書の内容を構成し、これを C に設定します。
• 3. 特定のダイジェスト アルゴリズムを使用して、オリジナル コンテンツ C のデジタル ダイジェストを計算し、H に設定します。
• 4. 最初のステップで生成された秘密鍵 S を使用してダイジェスト H に署名し、署名内容 S を取得します。
• 5. オリジナルコンテンツ C と署名済みコンテンツ S を結合すると、CA ルート証明書が取得されます。

CA 証明書: CA 組織によって他者に発行された証明書。主に以下の情報が含まれます

• 申請者の公開鍵
• 応募者の情報
• 発行者（CA）情報
• 上記の情報のデジタル署名。デジタル署名生成ルール: まず、SHA256 などのダイジェスト アルゴリズムを使用して上記の情報のダイジェストを生成し、次に CA が独自の秘密キーを使用してこのダイジェストを暗号化します。

(2) ビジネス関連証明書の生成

• 1. 企業は RSA などのアルゴリズムを使用して、公開鍵 K3 と秘密鍵 K4 のペアを生成します。
• 2. 公開鍵 K3 と証明書のその他の内容を作成して元の証明書の内容を作成し、それを C として設定し、認証局に渡します。
• 3. 権威ある組織は C を取得した後、要約アルゴリズムを使用して要約情報 2 を生成します。
• 4. 当局は、独自の秘密鍵 K2 (これが重要な点です) を使用して、要約情報 H に署名し、署名されたコンテンツ S を取得します。
• 5. オリジナルコンテンツC2と署名済みコンテンツS2を結合して証明書を取得し、企業に引き渡します。

CA ルート証明書とビジネス証明書の違いは次のとおりです。 ビジネス アプリケーションの証明書の署名に使用される秘密キーは、CA 機関の秘密キーです。この秘密キーは、ルート証明書の公開キーに対応します。

(3) 電子証明書の信頼性の検証

ルート証明書の公開キーを使用して、他の証明書の署名が正しいことを確認できます。署名が正しい場合、証明書は本物であり、改ざんされていません。後で、信頼された証明書に含まれる公開キーを使用して、受信したメッセージが信頼できるかどうかを検証できます。

10. 認証局 CA とは何ですか?

認証局 (認証局、CA) は、デジタル証明書の承認、発行、アーカイブ、および失効を担当する局です。

• CA機関は「ルートCA」と「中間CA」に分かれており、原則としてルートCA機関が直接エンドエンティティ証明書を発行することは避け、中間CA機関がエンドエンティティ証明書を発行する必要がある。
• これは、証明書の無効化による影響を回避するためであり、ルート証明書が無効または偽造されると、証明書チェーン全体に問題が発生します。

11. 証明書チェーンとは何ですか?

証明書チェーンは、複数のデジタル証明書によって確立される証明書検証チェーンです。

• デジタル証明書には主に、ユーザー情報、ユーザー キー、および証明書エンティティに対する CA 機関の署名の 3 つの部分が含まれています。
• 証明書の実体の正当性を検証するには、証明書を発行したCAの公開鍵を取得する必要があり、この公開鍵は上位証明書に存在します。したがって、証明書の正当性を検証するには、証明書チェーンをルート証明書まで追跡する必要があります。

ルート証明書は自己署名証明書であり、ユーザーがルート証明書をダウンロードするということは、ルート証明書によって発行されたすべての証明書を信頼することを意味します。オペレーティング システムまたはブラウザには、いくつかの信頼されたルート証明書がすでに組み込まれています。

12. 電子証明書の規格

デジタル証明書には主に、ユーザーの情報、ユーザーの公開キー、証明書の実体情報に対する CA の署名の 3 つの部分が含まれています。現在のデジタル証明書は公開鍵基盤 (PKI) によって策定された X.509 標準を採用しており、現在 3 つのバージョンがあり、このうち X.509 標準の 3 番目のバージョンがより一般的です。

• 主な形式は次のとおりです。
  

次に、openssl は自己署名証明書を生成します。

基本的なプロセス

仮想 CA 組織を構築し、証明書を生成し、
独自のキーを生成して、証明書認証アプリケーションに記入し、署名のために上記の CA 組織に提出し、
自己署名証明書 (自己構築した CA によって認証された) を取得します。組織）

• ルート証明書は https クライアントに組み込まれ、https サーバーの秘密キーによって生成されます。
  

まずは架空のCA認証局が出てくる

# 生成CA认证机构的证书密钥key
# 需要设置密码，输入两次
openssl> genrsa -des3 -out ca.key 1024

# 去除密钥里的密码(可选)
# 这里需要再输入一次原来设的密码
openssl> rsa -in ca.key -out ca.key

# 用私钥ca.key生成CA认证机构的证书ca.crt
# 其实就是相当于用私钥生成公钥，再把公钥包装成证书
openssl> req -new -x509 -key ca.key -out ca.crt -days 365
# 这个证书ca.crt有的又称为"根证书",因为可以用来认证其他证书

Web サイトの証明書を生成する

• 上記の架空の CA 組織を使用して認証を行う

# 生成自己网站的密钥server.key
# genra	生成RSA私钥
# -des3	des3算法
# -out server.key 生成的私钥文件名
# 1024 私钥长度
openssl> genrsa -des3 -out server.key 1024

# 生成自己网站证书的请求文件
# 如果找外面的CA机构认证，也是发个请求文件给他们
# 这个私钥就包含在请求文件中了，认证机构要用它来生成网站的公钥，然后包装成一个证书
# req 生成证书签名请求
# -new 新生成
# -key 私钥文件
# -out 生成的CSR文件
# -subj 生成CSR证书的参数
openssl> req -new -key server.key -out server.csr -subj "/C=CN/ST=Guangdong/L=Guangzhou/O=xdevops/OU=xdevops/CN=gitlab.xdevops.cn"

# 使用虚拟的CA认证机构的证书ca.crt，来对自己网站的证书请求文件server.csr进行处理，生成签名后的证书server.crt
# 注意设置序列号和有效期（一般都设1年）
# -days 证书有效期
openssl> x509 -req -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt -days 365 

これまでに、秘密キーserver.keyと証明書server.crtがすべて生成され、Webサイトのソースコードで使用できるようになりました。

• subj パラメータの説明は次のとおりです。
  

3. Android アプリケーションの署名

Gradle (10) v1/v2/v3 署名メカニズムを理解するための記事

https://duanqz.github.io/2017-01-04-Package-Manage-Mechanism

4. HTTPS相互認証（相互TLS認証）

HTTPS相互認証（相互TLS認証）

参考：

• 暗号化、ダイジェスト、署名、証明書を一挙にわかりやすく解説！
• 数秒でわかるHTTPSのCA証明書と自己署名証明書について
• ダイジェスト、署名、デジタル証明書とは何ですか?
• openssl は自己署名証明書を生成します (フルバージョン)
• OpenSSL を使用して自己署名 SSL 証明書を生成する
• openssl を使用して自己署名証明書を作成する
• Gradle (10) v1/v2/v3 署名メカニズムを理解するための記事