X.509 デジタル証明書の基本原則

I.はじめに

デジタル証明書は、現代のインターネットにおける個人間の相互信頼の基礎です。

電子証明書がなければ、さまざまな電子商取引プラットフォームや便利な電子決済サービスも利用できなくなります。

デジタル証明書はネットワーク セキュリティの非常に重要な部分です。ネットワーク セキュリティをよく学びたい場合は、その原則を完全に理解する必要があります。

これまでに説明したデジタル証明書はすべて、ITU によって策定された X.509 標準に基づいています。

この記事は純粋に個人的な学習体験の共有と交換を目的としたものであり、内容が多くて乱雑であるため、間違いは避けられず、参照のみを目的としています。

何か間違っている点を見つけた場合は、可能であればお知らせください。ありがとうございました。

2. 基礎知識

2.1 非対称暗号化

2 つのキーがあり、1 つは Key_1 で、もう 1 つは Key_2 です。

平文の一部が何らかの暗号化アルゴリズムによって Key_1 で暗号化された後、暗号文は Key_2 でのみ復号化できますが、Key_1 では依然として復号化できません。

逆に、平文を Key_2 で暗号化した後の暗号文は、Key_1 でのみ復号できますが、Key_2 では依然として復号できません。

この特性を満たす暗号アルゴリズムを非対称暗号アルゴリズムと呼びます。

現在一般的に使用されている非対称暗号化アルゴリズムは、RSA、DSA などです。

2.2 ダイジェストアルゴリズム

可変長のさまざまな「データ」を何らかのアルゴリズムで処理すると、必ず固定長のデータが生成されます。この固定長のデータを「ハッシュ値」と呼びます。

このアルゴリズムが以下の特性を満たす場合、要約アルゴリズムと呼ぶことができます。

• 可変長のさまざまな「データ」を簡単に「ハッシュ値」に生成できます。
• 「ハッシュ値」からは元の「データ」を推定することはできません。
• 同じ「ハッシュ値」を持つ別の「データ」を見つけることはできません。

現在一般的に使用されているダイジェスト アルゴリズムには、MD5、SHA-1、SHA-256 などが含まれます。

2.3 デジタル署名

デジタル署名とは、実際には「ハッシュ値」を非対称暗号アルゴリズムで暗号化した「暗号化ハッシュ値」です。

電子署名のワークフローは次のとおりです。

デジタル署名は通常、ID 認証と否認の防止に使用されます。

2.4 X.509デジタル証明書の構造図

簡単に言えば、デジタル証明書はデジタル署名が添付された情報シートです。

次の図は、この記事を理解するのに役立ちます。

2.5 インターネット上での一般的な情報盗難の手口

クライアント「C」がインターネットの反対側にあるサーバー「S」と機密性を保ったまま通信したいと考えており、クライアント「C」はサーバー認証メカニズムを導入していないとします。

2.5.1 偽サーバー

偽サーバー「fake_S」は「S」になりすまして「C」と直接通信します。

「C」がパスワードなどの機密情報を「S」に渡そうとした場合、その機密情報は「fake_S」によって傍受されます。

このとき、「fake_S」は通常、「C」にエラーを報告して撤退します。次に、「C」は実サーバー「S」と通信します。

このようにして、「fake_S」は機密情報を入手しました。そして、「C」もそれを認識しているでしょうが、ほとんどの人はネットワークが不安定であると考えており、それを気に留めていません。

現在、一般的ななりすまし手法としては、DNS スプーフィングなどが挙げられます。

2.5.2 中間者攻撃

偽サーバー「fake_S」は、「C」と「S」の間にブリッジを構築し、パケットを「C」から「fake_S」、さらに「S」に転送し、パケットを「S」から「fake_S」、そして「C」に転送できます。 」。

その後、「fake_S」は「C」と「S」の間のすべての通信を傍受し、データ パケットの内容を変更して積極的に攻撃を開始することもできます。

この攻撃手法は中間者攻撃と呼ばれます。中間者攻撃も非常に巧妙で、一般的に「C」は異常事態を検知できません。

現在、一般的なスプーフィング手法には、ARP スプーフィングと DNS スプーフィングが含まれます。

3. デジタル証明書の署名

RSA 証明書は例として使用されており、他のアルゴリズムの証明書は異なる場合があります。

3.1 ルート認証局の構築

簡単なプロセス

• ルート認証局「CA」は、公開鍵ca_KeyPub、秘密鍵ca_KeyPri、基本情報テーブルca_Infoを生成する。ca_Info には通常、「CA」の名前や証明書の有効期間などの情報が含まれます。
• ルート認証局「CA」は、(ca_KeyPub + ca_Info) に対してハッシュ演算を実行して、ハッシュ値 ca_Hash を取得します。
• ルート証明機関「CA」は、秘密鍵 ca_KeyPri を使用して ca_Hash を非対称暗号化し、暗号化されたハッシュ値 enc_ca_Hash を取得します。
• ルート認証局「CA」は、(ca_KeyPub + ca_Info + enc_ca_Hash) を組み合わせて、自己署名デジタル証明書「ca_Cert」を生成します。この証明書はルート証明書と呼ばれます。

ルート証明書「ca_Cert」には、ca_KeyPub + ca_Info + enc_ca_Hash が含まれます。

「ca_Cert」は、次のレベルの証明書に署名するために使用できます。

3.2 単一レベルの認証局による証明書署名

簡単なプロセス

• サーバ「S」は、公開鍵s_KeyPub、秘密鍵s_KeyPri、基本情報テーブルs_Infoを生成します。s_Info には通常、「S」の名前や証明書に必要な有効期間などの情報が含まれます。
• サーバー「S」は、s_KeyPub、s_Info をルート証明機関「CA」に送信します。
• ルート認証局「CA」が何らかの方法で「S」の身元を確認した後、ルート認証局自身の情報 ca_Info を追加し、ハッシュ演算 (s_KeyPub + s_Info + ca_Info) を実行してハッシュ値 s_Hash を取得します。 。
• ルート証明機関「CA」は、その秘密鍵 ca_KeyPri を使用して s_Hash を非対称暗号化し、暗号化されたハッシュ値 enc_s_Hash を取得します。
• ルート認証局「CA」は、(s_KeyPub + s_Info + ca_Info + enc_s_Hash) の組み合わせに署名してデジタル証明書「s_Cert」を作成し、それを「S」に送り返します。

サーバー証明書「s_Cert」には、s_KeyPub + s_Info + ca_Info + enc_s_Hash が含まれています。

「s_Cert」を使用して下位レベルの証明書に署名することはできません。

3.3 二次（またはそれ以上）の認証機関の構築

実際には、1 つの認証局だけに依存すると、大量の証明書の署名要件を満たすことができないため、ブランチ認証局を構築する必要があります。

簡単なプロセス

• 二次認証局「CA2」は、公開鍵ca2_KeyPub、秘密鍵ca2_KeyPri、基本情報テーブルca2_Infoを生成する。ca2_Info には通常、「CA2」の名前や証明書に必要な有効期間などの情報が含まれます。
• セカンダリ認証局「CA2」は、ca2_KeyPub と ca2_Info をルート認証局「CA」に送信します。
• ルート認証局「CA」が何らかの方法で「CA2」の身元を確認した後、ルート認証局自身の情報 ca_Info を追加し、ハッシュ演算 (ca2_KeyPub + ca2_Info + ca_Info) を実行してハッシュ値 ca2_Hash を取得します。 。
• ルート証明機関「CA」は、秘密鍵 ca_KeyPri を使用して ca2_Hash を非対称暗号化し、暗号化されたハッシュ値 enc_ca2_Hash を取得します。
• ルート証明機関「CA」は、(ca2_KeyPub + ca2_Info + ca_Info + enc_ca2_Hash) の組み合わせに署名してデジタル証明書「ca2_Cert」を作成し、それを「CA2」に送り返します。

二次認証局証明書「ca2_Cert」に含まれるコンテンツ: ca2_KeyPub + ca2_Info + ca_Info + enc_ca2_Hash。

「ca2_Cert」は、次のレベルの証明書に署名するために使用できます。

3 レベル以上の認証機関の構築プロセスもこのプロセスと似ているため、ここでは繰り返しません。

3.4 二次 (またはそれ以上) の認証機関による証明書の署名

簡単なプロセス

• サーバ「S2」は、公開鍵s2_KeyPub、秘密鍵s2_KeyPri、基本情報テーブルs2_Infoを生成する。s2_Info には通常、「S2」の名前や証明書に必要な有効期間などの情報が含まれます。
• サーバー「S2」は、s2_KeyPub と s2_Info を二次認証局「CA2」に送信します。
• セカンダリ認証局「CA2」が何らかの方法で「S2」の身元を確認した後、ルート認証局の情報 ca2_Info を追加し、ハッシュ演算（s2_KeyPub + s2_Info + ca2_Info）を実行してハッシュ値 s2_Hash を取得します。
• 二次認証局「CA2」は、秘密鍵 ca2_KeyPri を使用して s2_Hash を非対称暗号化し、暗号化されたハッシュ値 enc_s2_Hash を取得します。
• 二次認証局「CA2」は、(s2_KeyPub + s2_Info + ca2_Info + enc_s2_Hash) の組み合わせに署名してデジタル証明書「s2_Cert」を作成し、それを「S2」に送り返します。

サーバー証明書「s2_Cert」には、s2_KeyPub + s2_Info + ca2_Info + enc_s2_Hash が含まれています。

「s2_Cert」は、下位レベルの証明書の署名には使用できません。

第 3 レベル以上の認証局の証明書署名プロセスはこのプロセスと似ているため、ここでは繰り返しません。

上記からわかるように、証明書の署名プロセスは「ca_Cert」 -> 「ca2_Cert」 -> 「s2_Cert」です。これは完全なチェーンであり、これを「証明書チェーン」と呼びます。

3.5 実際の証明書署名

実際のほとんどの証明書は二次認証局によって署名されています。

また、サーバーの身元が何らかの方法 (DNS など) で検証されると、通常はサーバーに情報 (CSR ファイル) の提供を要求する必要はありません。

認証局は証明書、証明書チェーン、秘密キーを提供し、サーバーはそれを直接使用できます。

第四に、デジタル証明書の適用

4.1 要件

• サーバーとクライアントの間には、非対称暗号化を通じて安全な通信 (SSL/TLS) が実装されています。
• クライアントはサーバーの本当の身元を確認する必要があり、サーバーがなりすますことはできません。
• サーバーはクライアントの ID を検証する必要はありません。
• デジタル証明書は RSA アルゴリズムを使用します。

4.2 サーバー構成

サーバー「S」が使用する証明書がルート証明機関「CA」によって直接署名されている場合は、「s_Cert」をクライアントに提供するだけで済み、秘密鍵 s_KeyPri を使用して非対称暗号化を実現できます。

サーバー「S2」が使用する証明書がルート認証局「CA」によって直接署名されていない場合、「s2_Cert」だけでなく、ルート認証局「CA」を除くすべての認証局の証明書も提供する必要があります。そうしないと、クライアントは、証明書チェーンが不完全で検証に合格できないことを示すメッセージを表示する場合があります。サーバーは秘密キー s2_KeyPri を使用して非対称暗号化を実現できます。

4.3 クライアントはサーバーの ID を検証します

4.3.1 単一レベルの認証機関による検証

簡単なプロセス

（ルート証明機関「CA」のルート証明書「ca_Cert」がオペレーティングシステムにインストールされ信頼されているものとします。以下同様。）

• サーバー「S」は、クライアント「C」に証明書「s_Cert」を発行します。
• クライアント「C」は「s_Cert」の ca_Info をチェックし、それが「CA」によって署名されていることを確認します。
• クライアント「C」は、「ca_Cert」のca_KeyPubを取り出し、「s_Cert」のenc_s_Hashを復号してs_Hashを取得する。
• クライアント「C」は、「s_Cert」の(s_KeyPub + s_Info + ca_Info)に対してハッシュ演算を実行し、ハッシュ値s_Hash_tmpを取得します。
• クライアント「C」は、s_Hashとs_Hash_tmpが等しいかどうかを判定します。両方が等しい場合、「s_Cert」が「ca_Cert」によって署名されたことが証明されます。
• クライアント「C」は「ca_Cert」をチェックし、証明書がルート証明書であり、システムによって信頼されていることがわかり、ID 検証に合格します。

「ca_Cert」がシステムにインストールされていない場合、enc_s_Hash を復号化できず、「s_Cert」の信頼性を検証できません。以下同様。

4.3.2 二次（またはそれ以上）の認証機関による検証

簡単なプロセス

• サーバー「S2」は、証明書「s2_Cert」および「ca2_Cert」をクライアント「C」に発行します。
• クライアント「C」は「s2_Cert」の ca2_Info をチェックし、それが「CA2」によって署名されていることを確認します。
• クライアント「C」は、「ca2_Cert」のca2_KeyPubを取り出し、「s2_Cert」のenc_s2_Hashを復号してs2_Hashを取得する。
• クライアント「C」は、「s2_Cert」内の(s2_KeyPub + s2_Info + ca2_Info)をハッシュ演算し、ハッシュ値s2_Hash_tmpを取得します。
• クライアント「C」は、s2_Hashとs2_Hash_tmpが等しいかどうかを判定します。両方が等しい場合、「s2_Cert」が「ca2_Cert」によって署名されたことが証明されます。
• クライアント「C」は「ca2_Cert」の ca_Info をチェックし、それが「CA」によって署名されていることを確認します。
• クライアント「C」は、「ca_Cert」内のca_KeyPubを取り出し、「ca2_Cert」内のenc_ca2_Hashを復号してca2_Hashを取得する。
• クライアント「C」は、「ca2_Cert」の(ca2_KeyPub + ca2_Info + ca_Info)に対してハッシュ演算を実行し、ハッシュ値ca2_Hash_tmpを取得します。
• クライアント「C」は、ca2_Hashとca2_Hash_tmpが等しいかどうかを判定します。両方が等しい場合、「ca2_Cert」が「ca_Cert」によって署名されたことが証明されます。
• クライアント「C」は「ca_Cert」をチェックし、証明書がルート証明書であり、システムによって信頼されていることがわかり、ID 検証に合格します。

3 レベル以上の認証機関の証明書検証プロセスもこのプロセスと同様で、1 つずつ検証します。

4.4 送信データの暗号化

サーバー「S」の ID がクライアント「C」によって承認された後、サーバー「S」は s_KeyPri を使用して送信データを暗号化または受信データを復号化できます。

次に、クライアント「C」は s_KeyPub を使用して、送信データを暗号化したり、受信データを復号したりできます。

非対称暗号化は効率が低いため、通常は非対称暗号化を使用して一時セッション キーをネゴシエートおよび交換し、そのセッション キーを使用して対称暗号化を実行します。

4.5 実際の証明書検証

実際には、いくつかのよく知られ信頼できる認証局のルート証明書がオペレーティング システムに組み込まれています。

下の画像は、macOS 10.13.3 の組み込みルート証明書の一部です。

クライアントはサーバー証明書をチェックするときに、通常、その有効期間と、証明書が証明機関の証明書失効リストに含まれているかどうかもチェックします。証明書失効リストは通常​​、オンラインで確認されます。

5. シンプルな証明書システムを確立する

次の操作は、openssl パッケージがインストールされている Linux および macOS システムで実行できます。

ルート CA を自分たちで作成し、それを直接使用して証明書に署名します (つまり、単一レベル CA)。

証明書システム全体では、デフォルトで RSA4096 および SHA512 アルゴリズムが使用されます。

ルート認証局の有効期間は 10 年、署名付き証明書の有効期間は 1 年です。

5.1 作業ディレクトリを作成して
次のコマンドを実行します。

mkdir ~/test_pki && cd ~/test_pki

5.2 証明書のシリアル番号ファイルの
作成 次のコマンドを実行します。

echo 01 > serial

5.3 証明書データベース ファイルの作成
次のコマンドを実行します。

touch index.txt

5.4 openssl 設定ファイルの作成
次のコマンドを実行します。

cat << EOF >> test_pki.cnf

次の内容をコマンド ライン ウィンドウに直接貼り付け、Enter キーを押します。

[ ca ]
default_ca      = CA

[ CA ]
dir            = .    
database       = \$dir/index.txt         
new_certs_dir  = \$dir           

certificate    = \$dir/ca_cert.pem        
serial         = \$dir/serial            
private_key    = \$dir/ca_key.pem 
RANDFILE       = \$dir/.rand

default_bits = 4096
default_days   = 365                   
default_crl_days = 30                   
default_md     = sha512                    
unique_subject = no                     

policy         = policy_anything            

[ policy_anything ]
countryName             = supplied
stateOrProvinceName     = supplied
localityName            = supplied
organizationName        = supplied
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional
EOF

5.5 自己署名ルート証明機関の作成

次のコマンドを実行します。

openssl req -x509 -nodes -days 3650 -newkey rsa:4096 -keyout ca_key.pem -out ca_cert.pem -new -sha512 

結果:

（画面の指示に従って必要な情報を入力してください）

Generating a 4096 bit RSA private key
......................................................................................................................................................................................................................++
...................................................................................................................................................................................++
writing new private key to 'ca_key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value, 
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []: #国家码
State or Province Name (full name) []: #洲、省名
Locality Name (eg, city) []: #城市名
Organization Name (eg, company) []: #组织名
Organizational Unit Name (eg, section) []: #部门名
Common Name (eg, fully qualified host name) []: #常用名
Email Address []: #邮箱地址

実行後、ルート認証局証明書 ca_cert.pem とその秘密鍵 ca_key.pem が生成されます。

5.6 ユーザー証明書リクエストと証明書秘密キーの作成

次のコマンドを実行します。

openssl req -nodes -new -newkey rsa:4096 -keyout cert1_key.pem -out cert1_csr.pem

同様に、上記のプロンプトに従って関連情報を入力します。「チャレンジ パスワード []:」が表示された場合は、空白のままにして Enter キーを押します。

実行後、ユーザーの証明書要求ファイル cert1_csr.pem とその秘密鍵 cert1_key.pem が生成されます。

5.7 認証局の秘密キーを使用してユーザーの証明書に署名する

次のコマンドを実行します。

openssl ca -in cert1_csr.pem -out cert1_cert.pem -config test_pki.cnf

操作結果:

Using configuration from test_pki.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'CN'
stateOrProvinceName   :ASN.1 12:'Guangdong'
localityName          :ASN.1 12:'Shantou'
organizationName      :ASN.1 12:'yzn_cert'
organizationalUnitName:ASN.1 12:'yzn_cert'
commonName            :ASN.1 12:'yzn_cert'
emailAddress          :IA5STRING:'yzn_cert'
Certificate is to be certified until Mar 19 05:12:41 2019 GMT (365 days)
Sign the certificate? [y/n]: #输入 y 回车确认签署


1 out of 1 certificate requests certified, commit? [y/n] #输入 y 回车确认签署
Write out database with 1 new entries
Data Base Updated

実行後、ユーザーの証明書ファイル cert1_cert.pem が生成されます。

ユーザーは、認証と非対称暗号化に cert1_cert.pem および cert1_key.pem を使用できます。

5.8 結果の表示

ルート証明書 ca_cert.pem を macOS のキーチェーンにインポートして信頼として設定し、cert1_cert.pem をインポートしました。証明書の詳細を表示すると、次の結果が表示されます。

yzn_cert が確かに認証局 yzn によって署名されており、認証局 yzn がシステムによって信頼されていることは明らかです。こうして信頼の連鎖が築かれていくのです。