情報セキュリティ分野で暗号技術の活用が通信保護強化に寄与

ウェブサイトとか、組織とか、人とかとやり取りするとき、なんとなくセキュリティが気になってくることも多い。暗号技術って言われても、いきなり出てくる専門用語がちょっと多すぎて、一瞬戸惑う人も結構いるかもしれない。例えば、証明書だの公開鍵だの言われて、急に自分の秘密鍵を確認して、とか頼まれたとする。正直何から手をつければ良いか分からなくなる。キーの詰まったディレクトリを眺めながら立ち止まる――そういう状況に身を置いたことがある人もいるんじゃないかな。

このテーマは、公的鍵とか秘密鍵、証明書、それからハッシュみたいなものについて掘り下げてみようと思う。ただし、それらをどう運用・管理するかまでは触れずに。

暗号アルゴリズムという話になると、数学的な手順でデータを扱う仕組みっぽいイメージが湧く。中身としてはプライバシー保護や改ざん防止、あと本人確認にも使われてたりする。AESとかRSAとかSHA-二五六（実際には「数百」ぐらいのアルゴリズム名がある気もする）、こうした名前はどこかで耳にしたことがある人も多そう。それぞれ役割が違っていて、大雑把に三つぐらいのグループに分けられる印象だ――対称型（共通鍵）、非対称型（公開鍵）、そしてハッシュ関数。

暗号化という行為そのものは、「何倍もの複雑さ」で情報を変換して読み取れなくする目的で使われることが多い。パスワードでもファイルでも通信内容でも、とりあえず他人には見せたくない時に登場する技術。でもハッシュ関数だけはちょっと毛色が違っていて、「長さ固定の値」に変換して整合性チェックなんかによく使われる。

大きな枠組みとして考えるなら、多くの場合アメリカならNISTという団体推奨の規格がよく参照されている印象。他にも各国によって推奨される技術基準はいろいろ異なる場合もあるので、その辺りは要確認かな。

さて、本題の一部として暗号化について軽く触れておこうと思う。これは鍵（キー）と呼ばれる情報を元にデータをごちゃごちゃと変形させて、中身だけじゃぱっと見分からなくなった状態になる。そして、その逆操作――元通り読む作業――にも同じ種類または対応した別のキーが必要になっている場合がほとんど。

ここで出番なのが「対称暗号」と呼ばれる方式。一つだけ共通で使うパスワードみたいなキーで全部操作するイメージ。「共通鍵」「シークレットキー」などとも呼ばれていて、ファイルの保存時や休眠中データ、それから特定の通信プロトコル内でもよく採用されている手法だった気がする。もちろん現場によって微妙に呼び方や用途は違ったりもするけど…まあ、その辺りはケースバイケースだろうね。

秘密鍵暗号化の話は、どうもAESや3DESみたいなアルゴリズムがよく挙げられているみたいですね。数学的な手順で、いわゆる平文を何となく複雑な文字列に変換する仕組みです。そういえば、どこかの政府機関が推奨してる暗号方式も定期的に見直されているとか聞いたことがありますが、そのあたりは各自で確認した方が無難でしょう。

ファイル名の末尾とか気づいたことありませんか？「.enc」とか「.aes」、「.des」あるいは「.key」など、似たような拡張子がついてるものを時々目にします。それと、不思議と「1010101010101010」で始まったり終わったりしている鍵ファイルもちらほら…。

さて、非対称暗号について考えてみると、これは二つセットになったキー（公開鍵と秘密鍵）を使う方式です。データの暗号化だけじゃなくて署名検証にも絡んできますね。「公開鍵暗号」と呼ばれることもあれば、「証明書」と混同されてしまう場面もあります。SSLやTLS証明書、それから電子署名関連なんかで名前を聞くことも多いです。RSAやDiffie-Hellman、ECC、それからDSAなど、だいたい数種類程度が広く知られていますけど、その辺りも各国で少しずつ推奨アルゴリズムが違っていたりするので一概には言えない部分があります。

ふと思い出しましたけど、「公開鍵」「証明書」って言葉がごっちゃになる人も多そうですね。公開鍵というのは要するに誰でも手に入れて使えるキー（たぶんRSAだったりECCだったり）、これでデータを暗号化すると対応する秘密鍵以外では戻せません。そして電子署名の検証にも使われます。だいたい「.pub」や「.pem」という拡張子で保存されている場合が多く、「---BEGIN PUBLIC KEY---」や「---END PUBLIC KEY---」という記述で囲まれてます。

ところで、「証明書」は単なる公開鍵とはちょっと違います。所有者情報とか有効期限なんかを付加した状態になっていますね。そのため本人確認や信頼性チェックに活用されています。そして、多くの場合は認証局（CA）がサインしているので、一種のお墨付きみたいな役割になります。ただし必ずしも認証局が必要とは限らず、自分自身で署名した自己署名証明書という方法も残っています。でも、この自己署名タイプだとブラウザや他のクライアントソフトウェアには信頼されない場合が大半なので注意した方がいいでしょう。

余談ですが、自己署名された証明書ってどう見分けるんでしょう…。たしか発行者（issuer）と主体（subject）が同じになっているケースが多かったような気がしますね。こんな感じだったと思います…

「どうやってやるかは、また後で触れるとして……。公開鍵って、必ず認証局が必要なのかな？いや、そんなこともないみたいだ。公開鍵自体は、それぞれの人や組織が勝手に作ることもできるし。認証局（CA）の役割って、その公開鍵の持ち主を保証するためにデジタル証明書を発行することであって、最初から作成に関与しているとは限らない気がする。

じゃあHTTPSって、CAからしか導入できない？うーん……これも一応半分正しいけど違う部分もある。実際には、自分で署名した自己署名証明書でもHTTPSを動かせる。でも、それだと多くのブラウザで警告が出たりユーザーの信頼性が下がったりするケースが多いから、一般的には認証局によるものを使う場面が目立つ。

あと、「誰のものか知りたい時」には証明書は基本的に必要になる場合がほとんどだけど、絶対じゃないという話も聞く。証明書という形で公開鍵と身元情報を紐付けてくれることで所有者確認しやすくなる。ただ、人によってはフィンガープリントとか手動チェックとか他の方法を併用することもあるので一概には言えない感じ。

ちなみにファイル形式についてもちょっと触れておきたいけど、「.crt」とか「.cer」、「.pem」みたいな拡張子で保存されていて、『---BEGIN CERTIFICATE---』みたいな文字列で始まったり終わったりするパターン、多い印象だよね。

それとCA関連なら「ルート」と「中間」について少し混乱しそうな気もしたのでメモしておくと――ルート証明書は、大本の信頼されている認証局自身の所有物っぽい。一方、中間CA（Intermediate CA）は、そのルートCAから権限委譲された存在で、新たにデジタル証明書を発行できるようになっているらしい。この仕組みのお陰でスケールさせたり、安全性を高めたり（仮に中間CA側だけ問題起きても大本への影響は抑えられる）、色々利点あるっぽい。

なんとなくイメージとして、「チェーン」という考え方も押さえておいたほうが良さそう。「エンドユーザー向け（リーフ）」「中間」「ルート」という順番で繋げていく流れ。それぞれ次の階層によって署名されていて、一番上まで遡れる構造になっている。そのため、途中何か抜け落ちたり変だったりすると信頼されなくなる場合が多いようだ。

例えば例示すると――
・エンドユーザー：『example.com』用、中間CA発行
・中間：その中間CA自身へ発行されたもの（ルートCAより）
・そして一番上：大本のルート自身

クライアント側ではサーバー接続時、このチェーンを辿りながら本当に信頼できる相手か確かめようとする。でもまあ、全部完璧じゃなくても状況次第では多少融通効く場面もあるかもしれない、と感じることもある。

秘密鍵って、まあ持ち主がしっかり管理しなきゃいけないものなんだけど、よく見ると「.key」とか「.pem」みたいな拡張子がついてるファイルで保存されていることが多いらしい。始まりの部分とかに「---BEGIN PRIVATE KEY---」って書いてあったりして、なんとなく分かりやすい…はず。ただ、この手の鍵には必ず公開鍵も一緒についてきてて、その公開鍵単体だったり、認証局からサインされて証明書になったりすることもある。

ところでデジタル署名って言葉、何回も出てくる気がする。どちらかというと、「確認する」という行為が共通している感じだけど、本当の意味では送られてきたデータの信頼性とか改ざんされていないかを見極める役割を果たしている。細かな流れは、大まかにいうとこうだと思う。

まず、秘密鍵を持っている人が何らかのデータを作成すると、それに対してハッシュ関数という手法で短めの文字列――まあ指紋みたいなもの――を作る。この値自体は結構独特で、そのデータ専用みたいになる。そしてこのハッシュ値を秘密鍵で暗号化すると、不思議なことにそれ自体が署名として使えるようになるんだよね。

このあと、その人は元のデータと今作った署名（暗号化されたハッシュ）を受け取り側に送るわけ。でも受け取った側はどうやって本物だと確信できる？　そこで相手側は公開鍵でその署名部分だけ復号して元のハッシュ値っぽいものを取り出す。それから同じ方法でもう一度自分で届いたデータにハッシュ関数を適用して、新しいハッシュ値（さっきとは違う可能性もある）を計算する。その二つが一致すれば、「ああ、この文書変えられてないし、この人から来たんだろうな」と判断できそうだ。

何となくだけど、この方式なら発信者しか知らない情報（秘密鍵）がちゃんと生きてくるので、そこそこ安心感につながる場合もある。要点としては、秘密鍵所有者のみが署名できて、それを見る第三者――つまり公開鍵使う人――が内容チェック可能になる仕組みと言えそう。ただし世間的にはこれにも抜け道や限界が指摘されることもあるので、「絶対大丈夫！」とは言えない場面もありそうだ。

ちなみに数字とか正確な割合みたいなのは資料によって異なる場合もあるし、大雑把なくくり方になっちゃったけど、おおむねこういう仕掛けなんじゃないかなと思われる。

なんだか、やたらと長い記事だったような気がするけど――ざっくりまとめると、公開鍵とか秘密鍵を使った認証や暗号の仕組みについて話していたんだよね。プロジェクトで関わっている人たちも多くて、証明書とかキーの束に囲まれて「これ何？」って戸惑う場面、けっこうあるみたい。

まず、公開鍵は誰にでも渡せるものなんだそう。どこかのチームがデータを送信したい時、その相手の公開鍵を使って暗号化する。だから途中でデータが盗まれたりしても、中身は見られにくい（絶対じゃないかもしれないけど）。このあたり、何十回も説明聞いた覚えがある人もいそう。

そのあと、受け取った側は自分だけ持っている秘密鍵で解読するんだとか。ただ、その秘密鍵がしっかり管理されてないと意味がなくなるらしいので注意、と聞いたこともある。

ちなみにRSAみたいな方式では署名にも使われることが結構多い印象。誰かが自分の秘密鍵で署名すると、それを他の人は公開鍵でチェックできる仕組みになっている。まあ、このあたりになると「なんとなく理解してる」ぐらいで止まってしまう人、多いんじゃないかな？

細かいところまで突き詰めればまだ色々ありそうだけど、大体こんな流れだった……と思う。一部曖昧なところや例外もあり得るし、それぞれの現場ごとにルール違ったりするから、完全には言い切れないかな。

これでデータが改ざんされていないこと、まあ正しいっぽいという確認にはなる。キーファイルの種類にちょっと迷ったら、拡張子を見たりもするけど、たとえば.keyや.pemはプライベートキーって呼ばれるやつかもしれないし、.pubとか.pemはパブリックキーだったりする場合もあるみたい。.crtや.cer、それから.pemなんかも証明書として使われてることがある。ちなみに.pem形式って一種類だけじゃなくて、色々な鍵とか証明書で登場するので紛らわしい。

手元にある.pemファイルが何なのか調べたくなったら、catコマンドで中身をのぞいてみる方法がよく挙げられている。「---BEGIN PRIVATE KEY---」から始まればプライベートキー、「---BEGIN PUBLIC KEY---」なら公開鍵、「---BEGIN CERTIFICATE---」だと証明書、と大まかに分けて考える人もいる。ただ証明書の場合、中身が一枚だけとは限らず複数並ぶケースも珍しくない。サーバー証明書、中間CA、ルートCAなどが順番に並ぶことだってあり得る。

この鍵や証明書が実際どの用途なのか判断したい時は、大抵ファイル名にもヒントが混じっている気配。「server.pem」とついていたらサーバー用かな？「idpCert.pem」ならアイデンティティプロバイダー絡みっぽい印象を受ける。あくまで目安程度だけど。

さらに、この証明書自体の詳細な情報を知りたくなった場合、多くの人はopensslコマンドを試すようだ。「openssl x509 -in .crt -text -noout」を打つと、それなりに長い出力になる可能性が高い。その中には、有効期間・発行者・対象CN（コモンネーム）・拡張利用目的など色々含まれている。X509v3 Extended Key Usageという項目を見ることで、その証明書がおおよそ何向き（例えばTLSウェブサーバ認証用なのかどうか）なのかわかることも多そう。ただ全てのケースではないし、状況によって若干違う表記になっている場合もちらほら見受けられる。

証明書の話って、たいてい一度は耳にしたことがあるかもしれない。自己署名証明書って言われるやつは、発行者と所有者が同じ名前だったりするみたい。だから実際にコマンドで中身を確認してみると、どこかに「Issuer」と「Subject」っていう項目があって、それがそっくりそのまま一致していたら、それなんだろうね。

所有している証明書の秘密鍵は誰のものなのか…これも結構迷う人多いかも。`openssl x509 -in

.crt -text -noout` というコマンドで覗くと、「CN」または「Common Name」っていうところの値が出てくる。その表示されている名前、例えば「www.example.com」みたいなやつが、その秘密鍵を持つエンティティになるんじゃないかなぁ、と考えられている。



データを扱うアルゴリズムについても調べられる方法ある。「Signature Algorithm」っていうフィールドを見ることで分かるそうだ。例えば「sha256WithRSAEncryption」と書いてあったら、それを使っている可能性高いよ。でも環境によって違う場合もたぶんある。



あと、「.key」が非対称暗号なのか共通鍵方式なのか知りたい時にはどうしたらいいの？という疑問も出てきたりする。ファイルをそのまま `cat filename.key` で開いて、中身がバイナリっぽかったら（数字や記号が並んで読めない感じ）、それは共通鍵型の場合もある。でもテキストっぽくて読めそうなら、多分公開鍵・秘密鍵ペアの非対称暗号なんじゃないかなと思われている。ただし例外や特殊な形式も存在するので、一概には断言できない部分も見受けられる。



ハッシュ関数について語るなら、まあざっくり言えば元データから決まりきった長さの文字列（ハッシュ値）に変換しちゃう技術。それぞれ用途はいろいろで、パスワード管理とかデータ改ざんチェックとか署名作成などにも活用されている。でも全体像を把握しようとすると、細部まで理解するには少し時間が要る気がする。