このドキュメントは http://edu.net.c.dendai.ac.jp/ 上で公開されています。
暗号とは、送りたい情報(平文)を別の情報(暗号文) に置き換え、送りたい情報そのものを秘匿する技術です。 但し、鍵を持っていると、暗号文から元の平文を求める (復号)できることが必要です。 平文から暗号文を 作る操作を暗号化と言いますが、これは一般 には鍵に対する 暗号関数 と復号関数 により次の関係を示すことができます。
は必ず存在しなければならないので、鍵の全探索 (ブルートフォースアタック) により、暗号は必ず解くことができます。 但し、鍵の全体集合(鍵空間)が十分に大きければ、ブルートフォースアタック に対して、解かれにくくなります。 暗号への攻撃はブルートフォースアタックのみではありません が、 様々な攻撃への耐性のことを強度と言います。 鍵空間の大きい暗号は、ブルートフォースアタックに対して強度を持つこと になります。
文字に順番がある時、文字列を暗号化するときに、それぞれの文字の順番を ずらすのをシーザー暗号 と言います。
これは鍵空間が狭いので、ブルートフォースアタックで簡単に解けます。
文字を入れ替えて作る暗号を単一換字式暗号と言います。 鍵空間は広いのですが、元の平文の性質をそのまま持つため、 英語だと「eが多い」「一文字の単語は a, I」「the, are, with などよく 出てくる単語にパターンがある」などのテクニックで解けます。
したがって、ブロック暗号を作る場合は、ある程度ブロック長を長く取る必 要があります。
古くから使われている暗号は、暗号化の手法から復号の手法がすぐにわかる ようなものです。 このような暗号を共通鍵暗号と言います。 一方、暗号化鍵を知っても復号化が直ちにできないような暗号は、暗号化鍵 を公開しても安全性が保たれます。これを、公開鍵暗号と言います。 古典暗号理論では鍵は秘匿しながら受信者と共有しなければなりませんでした が、その共有するのに、どのような通信を行えばよいかという 鍵配布問題は未解決問題でした。
ところが、Diffie と Hellmanは暗号鍵から復号鍵が求めにくいような暗号 システムを提案しました(1976)。 このシステムでは受信者が暗号鍵を盗聴可能な通信路で送信者に送れば、 平文は盗聴されずに通信が行なえます。 このようなシステムを公開鍵暗号システムと言います。 公開鍵暗号は根本的に鍵配布問題を解決します。
Rivest, Shamir, Adleman が開発した公開鍵暗号方式（1977）。
2つの素数 p, q の積に対する オイラー関数は次で得られます。
ここで、以下の条件を持つ、ある２つの数 e,d を求めます。
すると、p,q と互いに素な数 x に対して次が成り立ちます。
ここで、e,n=pq から d を求めるのは、 p,q を知っていれば容易ですが、 そうでなければ有効なアルゴリズムは知られていません。 そこで、暗号化鍵、復号化鍵を次のように定めると、公開鍵暗号であるRSA 鍵を作ることができます。
公開鍵暗号では、公開鍵は一般に知られますが、秘密鍵は誰にも知られずに 運用できます。 従って、「秘密鍵を持っている」という情報は、公開鍵と秘密鍵を作ったと いう証明になります。
公開鍵を使って、秘密鍵を持っているという情報を示すことができれば、個 人認証をすることができます。 もし平文を秘密鍵で暗号化でき、公開鍵で復号できるのであれば、その平文 と暗号文のペアを示すことで、秘密鍵を持っていることを証明できます。
なお、このような設定に対して、第三者が偽の公開鍵をばらまいてなりすま しをする第三者攻撃が考えられます。 この、第三者攻撃は考え方によっては全く防ぐ方法はありません。 しかし、もし、予め、なりすましされない人の公開鍵を全員が持つことがで きる状況を考えます。 そして、それとは別の通信をしたい人が、公開鍵をその人に署名してもらえば、 なりすましでないことがわかります。 そのような署名を行う役割を証明局と言い、証明局の公開鍵は 全員で共有されます。 さらに、証明局に署名してもらった鍵で、他の公開鍵を署名すれば、その署 名をたどり、証明局にたどり着くことで、なりすましでないことが分かりま す。 そのため、証明局の証明書（公開鍵を含む）を予めの配布と、鍵の署名の連 鎖を示す証明書により、第三者攻撃を防ぐことができます。
ハッシュ関数とは一般的には情報の一部を取り出して、大雑把 な情報処理を行うものです。 例えば、個人情報に関して、誕生日というのは情報の一部なので、ハッシュ 関数から得られた値と考えることができます。 誕生日が異なる2人は同一人物ではなく、また、誕生日はほぼ均等に分布して いるので、同じ誕生日毎に処理を行うと、一度の処理を1/365 位のデータ量 に抑えることができます。小さい病院のカルテ整理の方法で見たことがあります。 しかし、一方、一般的に誕生日は個人を特定するのに重要な情報であるため、 個人情報を秘匿したまま情報処理を行いたい場合に使用することはできませ ん。 暗号として使うことはできません。
大きなドキュメントをいくつか扱う場合、ドキュメントから有限の情報を取 り出して処理できると便利なことがあります。 ドキュメントの一部を取り出したものをダイジェストと呼びま す。 例えば、学生のレポートのダイジェストを考えた場合、冒頭の100文字とか をダイジェストとすると、本来はそれぞれの内容が異なっていても、ダイジェ ストは似通ってしまいます。 従って、ダイジェスト自体にも望む性質が考えられます。
暗号理論的ハッシュ関数に必要な性質とは次のようなものです。
なお、さらにハッシュ値のうち、固定長で非常に短いものを フィンガープリントとも言います。
インターネットを使用する上で、様々な暗号技術を使用します。 単純に考えると、通信内容のやり取りが暗号化されていれば良いので、統一的 な暗号方式があるか、或いは、アプリケーションで暗号化していれば良いと 思えます。 この統一的な暗号方式として、各アプリケーションに対して統一的に用いる 暗号通信として TLS (Transport Layer Security)があります。 アプリケーション用の暗号ライブラリも整備されています。
その他にもレイヤー2からレイヤー4まであります。
レイヤ2では 通信内容が物理現象としてやり取りされています。 そのため、特に無線ネットワークなどでは、電波の傍受に対する秘匿性が必要 となります。 さらに、ネットワークに接続する時、認証をする必要があります。 この際、パスワードなど個人認証に必要な情報が流れますが、秘匿する必要が あります。 認証はインターネットに接続するための手続きですが、それをする状況ではま だインターネットに接続しておらず、レイヤ2通信のみが可能な状況です。 この、ネットワークに接続する際に行われる認証のための暗号通信は、 EAP(Extensible Authentication Protocol)として規定されています。 そして、無線LANでは WPA2, WPA3 、有線LANでは 802.1Xという方式で実現さ れています。 大学のネットワーク認証が、学籍番号とパスワードで認証可能なのは、この EAPにより、インターネット上に設置されている認証サーバと、各無線LANアク セスポイントや、情報コンセントが通信しあって認証を行うことで実現してい ます。
レイヤ3による暗号通信とは、通信の転送の際の暗号通信です。 これは、ルーター・ルーター間の暗号通信になります。 これにより、IPパケットを暗号化して、通常のIP通信により通信を行うこと ができます。 この用途としては、外部から秘匿したい2つの離れたプライベートネットワー ク同士をインターネットで接続するために使われます。 暗号自体は IPsec と呼ばれますが、用途としては VPN(Virtual Private Network)と呼ばれます。
本学では、大学内のネットワークに大学の外からつなぐ VPN サービスが提 供されています。 これは、パソコンでVPNサービスを設定すると、大学の外でも大学のネット ワークにつながっている状態になります。 これを利用すると、 研究的には研究室のサーバに接続しやすくなる他、 大学からのアクセスが許されている外部データサービスなどにアクセスがで きるようになります。
レイヤ4の暗号についてはSOCKSという技術がありますが、 現在は余りポピュラーではありません。 レイヤ4なので、サーバー、クライアントの両方が対応していれば、どのよ うなネットワークに接続していても、全ての サービスで暗号通信が可能に なります。 そのための、プロトコルライブラリのインストールが必要になります。
なお、Opensshという暗号を利用したネットワーク接続サービスでは、ポー トフォワーディング機能があり、任意のTCPのポートを転送する機能があり ます。
アプリケーションでTLSを使用するにはサービスに関するサーバとクライ アントの両方が TLS に対応している必要があります。 HTTPSについては、クライアントであるブラウザはほとんどが TLS に対応し ています。 つまり、ライブラリを持っていて、さらに認証局の公開鍵を全て持っていま す。 但し、SSL1.0, 2.0, 3.0, TLS 1.0, 1.1 は危険性が発見され、廃止になっ ているため、古いAndroid端末やWindows XP などのブラウザは現在のHTTPS サーバが使う TLS1.2, TLS1.3に対応できず、通信ができません。
一方、サーバについてはそれぞれのサーバがTLSに対応する必要があります。 TLS に対応するには、TLS の使えるサーバの他、認証局に署名してもらった 証明書が必要となります。
TLSに対応したサーバとクライアントが通信をする場合、証明書のチェック や、使用する暗号などのやり取りは自動的に行われ、ユーザにとっては対応 していない通信と操作性は変わりません。 但し、証明書に問題がある場合は検知されユーザに知らされます。
多くのブラウザにおいて、HTTPS で暗号通信が成立すると、鍵マークが画面 に表示されます。 更に、緑や青の表示がされる場合があります。
TLSの運用には証明書が必要です。 この証明書の書式やフォーマットは規定されています。 X.509はITU-Tの定めた公開鍵証明書の規格です。 但し、RFC5280「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile」 が規定されてい、これが運用されています。 署名の連鎖を表すために、証明する側である発行者と、証明される側である 主体者の欄があります。 また有効期限もあります。 大規模システムがこの証明書の期限切れでダウンするトラブルがしばしば発生 しています。 興味がある人は「証明書 期限切れ 障害」で事例を検索してみて下さい。 さらに、近年は期限が長すぎる証明書は危険な証明書と見なされることもあり ます。 例えば、 Apple製品は 2020年9月より証明書の有効期限は397日以内でないと接続できなくなります。
証明書のファイルの形式にはいくつかあります。 PEM形式という、Base64 方式で符号化された証明書で、「-----BEGIN CERTIFICATE-----」と「-----END CERTIFICATE-----」で囲まれているもの の他、 DERやCERや、RSAセキュリティ社により規定されたPKCS(Public-Key Cryptography Standards)で定められている、P7CやP12 などがあります。
発行者と主体者の一致する証明書を自己証明書と言いま す。 認証局の証明書は自己証明書です。 クライアントが自己証明書を確認するには、クライアント自身が自己証明書 持っている必要があり、通常はブラウザやOSなどに含まれています。
認証局でなくても、自己証明書は簡単に作れます。 TLSが前提としているセキュリティでは、認証局やブラウザやOSを信用するこ とが必要です。 しかし、これらは全て民間団体であるため、これら全てを信用しないとい う立場があります。 つまり、これに対して、サーバに自己証明書を使い、さらに利用者に対しては その証明書が正しいものとしてブラウザに別途証明書を手動でインストール するという立場も考えられます。 政府認証基盤（GPKI）https://www.gpki.go.jp/や 地方公共団体組織認証基 盤https://www.lgpki.go.jp/で は、実際にその組織が作成した自己証明書を配布していて、それを利用者に インストールするように求めています。 このページ自体のなりすましを防ぐために、自己証明書のフィンガープリン トも表示しています。 なお、この場合のフィンガープリントはネットワークから取得するのは正し くなく、官報などネットワークとは独立した信用できる通信網から取得し、 確認することが必要です。 ただ、インストール時にネットワーク上のフィンガープリントと照合し、後 に、ネットワーク上のフィンガープリントと官報のフィンガープリントの照 合をする運用でも、ネットワーク上のフィンガープリント自体が衆人監視の 下にあるので、安全性を大きく失っていることにはなりません。
一方、自己証明書に対して、公開鍵を持っていなくても大目に見て暗号通 信を行うクライアントが多くあったため、取り敢えずの暗号通信を実現させ るために、自己証明書を使っているサイトが多くありました。 しかし、近年、セキュリティのエラーは大目に見られなくなってきました。 近年のブラウザは証明書のエラーのあるページを表示しないようになってき ました。
一方で、HTTP2 や HTML5 などで HTTPS を推奨するようになって来ています。 また、 Internet Security Research Group が提供している Let's Encryptという 認証局は無料で自動的に認証を行うサービスを提供しています。 このスポンサーは電子フロンティア財団、Mozilla Foundation、ミシガン大 学、アカマイ・テクノロジーズ、シスコシステムズです。 これにより、近年、正常な認証されたサーバが増えてきています。
なお、本授業サーバが暗号通信化していない理由は、暗号化の必要性を感じ ていないからです。 また古いWebブラウザで閲覧できないことに、多少のデメリットを感じています。
TLSアプリケーションの開発などでは、TLSライブラリを利用しつつも手作業 で介入できるフロントエンドのソフトウェアが必要です。 openssl はそのためのプログラムです。 Windows では https://slproweb.com/products/Win32OpenSSL.html からWin64 OpenSSL v3.1.1 Lightの msi ファイルをインストールできます。 MacOSX や Linux だと標準でインストールされていて、そのまま利用できます。
HTTPサーバに対して
openssl にはサーバー接続機能の他、暗号、証明書、ダイジェスト、署名、 タイムスタンプなど、あらゆる TLSに関することができます。 但し、そのために、ファイル指定のルールやコマンドの書式などの利用には テストや熟練が必要です。