dcmtls における証明書と認証局の管理
システム証明書と秘密鍵
TLS プロトコルでは、サーバ（すなわち TLS ネットワーク接続を受け付けるアプリケーション）は証明書と秘密鍵を使って自身を暗号学的に証明しなければなりません。一方、クライアント（TLS ネットワーク接続を開始するアプリケーション）は証明書と秘密鍵で自身を証明してもよいですし、匿名のままでも構いません。
TLS 暗号化ネットワーク接続をサポートする DCMTK のツールはいずれも、暗号化なしの通信、証明書付き TLS、あるいは（クライアントアプリケーションの場合）匿名モードの TLS を選ぶためのコマンドラインオプションを備えています。
-tls --disable-tls- 通常の TCP/IP 接続を使う（既定値）
+tls --enable-tls [p]rivate key file, [c]ertificate file: string- 認証付きのセキュアな TLS 接続を使う
+tla --anonymous-tls- 証明書なしのセキュアな TLS 接続を使う
証明書・秘密鍵・その他の暗号関連データには、2 つのファイル形式がサポートされています。1 つは既定であるテキストベースの PEM 形式（"Privacy Enhanced Mail"）、もう 1 つは DER 符号化（"Distinguished Encoding Rules"）によるバイナリの ASN.1 ファイルです。ファイル形式は次のオプションで選択できます。
-pem --pem-keys- 鍵と証明書を PEM ファイルとして読み込む（既定値）
-der --der-keys- 鍵と証明書を DER ファイルとして読み込む
なお、PEM 形式は 1 つのファイルに複数の証明書を含められます。これは中間 CA が発行した証明書を TLS で使う際に重要な機能となります。DER 形式は 1 ファイルにつき 1 証明書しか扱えません。
秘密鍵は暗号化された状態で保存されていることが多く、その場合は秘密鍵ファイルを復号するためのパスワードが必要になります。このときには次のオプションが用意されています。
+ps --std-passwd- 標準入力からパスワードの入力を求める（既定値）
+pw --use-passwd [p]assword: string- コマンドラインで指定したパスワードを使う
-pw --null-passwd- 空文字列をパスワードとして使う
セキュリティプロファイル
DICOM 規格は、TLS 上で DICOM ネットワークプロトコルを使うためのセキュリティプロファイルをいくつか定義しています。DCMTK は以下のプロファイルをサポートします。
+pg --profile-8996- BCP 195 RFC 8996 TLS Profile（既定値）
+pm --profile-8996-mod- Modified BCP 195 RFC 8996 TLS Profile # このプロファイルに必要なすべての TLS 機能を、基盤となる TLS ライブラリがサポートしている場合にのみ利用可能
+py --profile-bcp195-nd- Non-downgrading BCP 195 TLS Profile（廃止）
+px --profile-bcp195- BCP 195 TLS Profile（廃止）
+pz --profile-bcp195-ex- Extended BCP 195 TLS Profile（廃止）
+pb --profile-basic- Basic TLS Secure Transport Connection Profile（廃止） # 基盤となる TLS ライブラリが 3DES をサポートしている場合にのみ利用可能
+pa --profile-aes- AES TLS Secure Transport Connection Profile（廃止）
+pn --profile-null- 認証付き非暗号化通信（廃止、IHE ATNA で使われていた）
既定で選択される BCP 195 RFC 8996 TLS Profile は、それ以前の BCP 195 系プロファイルとの後方互換性を保ちつつ安全な選択肢となっています。ただし、それより古いプロファイルとの後方互換性はありません。TLS バージョン 1.2 または 1.3 を使い、可能なら TLS 1.3 を既定とします。
Non-downgrading BCP 195 TLS Profile は DCMTK 3.6.7 での既定値であり、古いプロトコルバージョンと暗号スイートを同様に無効化します。ただし DHE 暗号スイートはサポートしており、これらの使用は避けるべきだと RFC 9325 が勧告している点が異なります。TLS バージョン 1.2 または 1.3 を使い、可能なら TLS 1.3 を既定とします。
BCP 195 TLS Profile は DCMTK 3.6.6 までの既定値で、現在も安全とみなされている暗号アルゴリズムをネゴシエートしようとしますが、廃止された AES または Basic TLS プロファイルを実装した古いアプリケーションとの後方互換性も提供します。このプロファイルは RFC 8996（2021）で改訂された BCP 195 にはもはや準拠していません。
Extended BCP 195 TLS Profile は Non-downgrading BCP 195 TLS Profile に似ていますが、暗号スイートの選択がより限定的で、TLS バージョン 1.2 に制限されています。
AES TLS Secure Transport Connection Profile は AES 暗号化と TLS バージョン 1.0 以降を使い、DICOM 規格からは廃止されています。このプロファイルを実装したデバイスとの後方互換性が必要な場合にのみ使うべきです。
Basic TLS Secure Transport Connection Profile は Triple DES 暗号化と TLS バージョン 1.0 以降を使い、これも DICOM 規格から廃止されています。このプロファイルを実装したデバイスとの後方互換性が必要な場合にのみ使うべきです。特に、実効鍵長 112 ビットでは総当たり攻撃に対してもはや十分に安全とは言えないためです。
最後の認証付き非暗号化通信は、旧バージョンの IHE Audit Trail and Node Authentication プロファイルで定義されていた廃止プロファイルです。暗号学的チェックサムを伴う非暗号化通信を使います。このプロファイルは避けるべきです。
なお、Basic TLS プロファイルのサポートは、OpenSSL ライブラリが Triple DES のサポートを有効にしてコンパイルされている場合にのみ利用できます。これはもはや既定では有効になっていません。
TLS ハンドシェイク時に提示する TLS 暗号スイートの一覧は、次のオプションで拡張できます。
+cs --cipher [c]iphersuite name: string
add ciphersuite to list of negotiated suites
サポートされている TLS 1.0〜1.2 の暗号スイートの一覧は、次のオプションで表示できます。
+cc --list-ciphers
list supported TLS ciphersuites and exit
オプション --cipher は複数回指定して、複数の暗号スイートを追加できます。
相手認証
既定では、dcmtls の TLS 実装はクライアントとサーバの双方に身元証明としての証明書の提示を求め、その証明書の有効性と信頼性を検証します。この処理には次のいくつかの段階があります。
- TLS ハンドシェイクでは、証明書に符号化された公開鍵に対応する秘密鍵にアプリケーションがアクセスできることの証明が求められます。
- 証明書内の電子署名が検証されます。
- 証明書の有効期間が確認されます。
- 証明書が信頼された認証局（CA）によって発行されたものかどうかが確認されます（認証局を参照）。
- コマンドラインオプションに応じて、ルート CA までのすべての CA の証明書失効リスト（CRL）を照合し、証明書チェーン内のいずれかの証明書が失効していないかを確認する場合があります（証明書失効リストを参照）。
この動作は次のコマンドラインオプションで変更できます。
-rc --require-peer-cert- 相手の証明書を検証し、存在しなければ失敗とする（既定値）
-vc --verify-peer-cert- 相手の証明書が存在する場合に検証する
-ic --ignore-peer-cert- 相手の証明書を検証しない
1 つ目のオプションは、相手が証明書を提示しない（すなわち匿名モードで動作している）場合や、証明書を完全に検証できない場合に接続を失敗させます。2 つ目のオプションは、証明書が存在すれば検証を行いますが、匿名接続も受け入れます。3 つ目のオプションは証明書の検証を一切行わず、匿名接続も受け入れます。
なお、後者の 2 つのモードは中間者攻撃に対して脆弱であり、避けるべきです。
--verify-peer-cert オプションはクライアントアプリケーションでは利用できません。TLS サーバは常に証明書を提示するためです。
認証局
TLS 暗号化ネットワーク接続をサポートする DCMTK のすべてのツールには、信頼されたルート証明書（すなわち自己署名証明書）の一覧が必要です。これは TLS 接続を確立する際に相手の証明書を検証するために使われます。
この信頼された証明書の一覧を管理する方法は 2 つあり、ファイルベースとディレクトリベースです。DCMTK のコマンドラインツールは、この目的のために次のコマンドラインオプションを提供します。
+cf --add-cert-file [f]ilename: string- 証明書ファイルを証明書一覧に追加する
+cd --add-cert-dir [d]irectory: string- d 内の証明書を証明書一覧に追加する
どちらのオプションも複数回指定でき、組み合わせて使うこともできます。
信頼されたルート証明書のファイルベース管理
ファイルベースのオプションはファイルを読み込み、その中に含まれるすべての証明書または CRL を信頼された証明書のプールに追加します。ファイル形式は、PEM 形式の証明書と CRL を連結した ASCII テキストです。ただし ASN.1 DER 形式が選択されている場合は除きます。
信頼されたルート証明書のディレクトリベース管理
ディレクトリベースのオプションは、証明書と CRL を含むディレクトリを指定します。これらの証明書と CRL は必要に応じて読み込まれ、一度読み込まれるとメモリにキャッシュされます。
ディレクトリには、1 ファイルにつき 1 つの証明書または CRL を PEM 形式で置きます。ファイル名は証明書なら hash.N、CRL なら hash.rN の形式とします。ハッシュは、証明書の場合はサブジェクト名から、CRL の場合は発行者名から計算されます。ハッシュ値は openssl コマンドラインツールを呼び出して得られます。
openssl x509 -hash -noout -in <infile.pem>
ここで
.N または .rN というサフィックスは 0 から始まる連番で、同じハッシュ値を持つ証明書または CRL ごとに連続して増加します。連番に欠番があってはならず、連番中で最初に欠けた番号より先には同じハッシュのオブジェクトは存在しないものとみなされます。
連番によって、同じサブジェクト名のハッシュ値を持つ複数の証明書をディレクトリに格納できます。たとえば、同じサブジェクトを持つ複数の証明書や、同じ発行者を持つ（有効期間などが異なる）複数の CRL をストアに置くことが可能です。
中間 CA
多くの場合、システム証明書はルート CA（すなわち自己署名証明書を使う CA）によって直接署名されるのではなく、中間 CA によって署名されます。その中間 CA の証明書はルート CA（あるいはさらに上位の中間 CA）によって署名されます。
TLS ハンドシェイクでは、アプリケーションは複数の証明書を提示できます。すなわち、自身の証明書に続けて、ルート CA 証明書まで（任意でルート CA 証明書を含めて）の中間 CA の証明書を提示できます。
DCMTK のツールは、こうした中間証明書が --enable-tls オプションの 2 番目の引数として渡されるシステム証明書と同じファイルに含まれていれば、TLS ハンドシェイク時にそれらを提示します。これには PEM 形式が必要です。DER は 1 ファイルに複数の証明書を扱えないためです。
PEM 形式では、証明書をテキストファイル内に単純に連結できます。システム証明書を先頭に、続いて中間 CA 証明書、最後に任意でルート CA 証明書を並べます。Linux/Posix システムでは、このようなファイルを次のように作成できます。
cat system_cert.pem intermediate_ca.pem root_ca.pem > fullchain.pem
LetsEncrypt の証明書を使っているユーザは、LetsEncrypt がこうした証明書チェーンを含む "fullchain.pem" ファイルを自動的に提供することに気づくでしょう。
--add-cert-file または --add-cert-dir で信頼できるものとして定義できる証明書は、ルート CA 証明書のみです。中間 CA 証明書を「トラストストア」に追加することはできません。
証明書失効リスト
証明書検証の最後の任意の段階は、証明書失効リスト（CRL）を参照し、証明書チェーン内のいずれかの証明書が失効していないかを確認することです。CRL は TLS ハンドシェイクで伝送できないため事前に設定しておく必要があり、CRL 自体にもファイル内で定義された有効期間がある点に注意してください。
次の CRL オプションは DCMTK 3.6.7 以降で利用できます。
+crl --add-crl-file [f]ilename: string- 証明書失効リストファイルを追加する（--enable-crl-vfy を含意する）
+crv --enable-crl-vfy- 末端の CRL 検証を有効にする
+cra --enable-crl-all- チェーン全体の CRL 検証を有効にする
--add-crl-file オプションは、CRL 参照に使う CRL ファイルを読み込みます。このオプションは複数回指定できます。あるいは、CRL ファイルを --add-cert-dir で指定した CA ディレクトリに置くこともできます。この場合の CRL ファイルの命名規則については信頼されたルート証明書のディレクトリベース管理を参照してください。
--enable-crl-vfy オプションは、末端 CA の CRL の参照を有効にします。すなわち、相手のシステム証明書が失効しているかどうかを判断するために 1 つの CRL のみを確認します。--enable-crl-all オプションは、ルート CA までのすべての CRL の参照を有効にし、中間 CA 証明書が失効している場合もカバーします。
いったん CRL 検証を有効にすると、必要な CRL のいずれかが欠けている場合は証明書検証が失敗します。