List of Pki - text.Baldanders.info
tag:text.Baldanders.info,2020-10-13:/tags
2020-10-13T15:49:24+09:00
帰ってきた「しっぽのさきっちょ」
https://text.baldanders.info/images/avatar.jpg
https://text.baldanders.info/images/avatar.jpg
個人番号カードの電子証明書を更新した
tag:text.Baldanders.info,2020-10-13:/remark/2020/10/update-my-number-card/
2020-10-13T06:49:24+00:00
2020-10-13T07:18:27+00:00
オンラインでの更新は出来ない。
Spiegel
https://baldanders.info/profile/
<p>5年前に広島市で<a href="https://text.baldanders.info/remark/2016/02/my-number-card/" title="個人番号カードを発行してもらいました">個人番号カードを発行してもらった</a>ときに「電子証明書の利用期限前にアナウンスすることはない」と言われたのだが「<a href="https://dic.pixiv.net/a/%E3%81%82%E3%82%8C%E3%81%AF%E5%98%98%E3%81%A0">あれはウソだ</a>」ったらしい(笑)</p>
<p>松江市からきっちり「有効期限通知書」が来たので,いそいそと出掛けたですよ(オンラインでの更新は出来ない)。</p>
<figure style='margin:0 auto;text-align:center;'><a href="https://www.flickr.com/photos/spiegel/50465658593/"><img src="./50465658593_5ce36af6d8_e.jpg" srcset="./50465658593_5ce36af6d8_e.jpg 500w" sizes="(min-width:600px) 500px, 80vw" alt="松江市役所 | Flickr" loading="lazy"></a><figcaption><div><a href="https://www.flickr.com/photos/spiegel/50465658593/">松江市役所 | Flickr</a></div></figcaption>
</figure>
<p>更新の際には「有効期限通知書」が必要(「有効期限通知書」に裏書きして代理人に依頼することも可能)。
もちろん個人番号カードも忘れないこと。
電子証明書の更新だけなら顔写真は不要。
何故か最近また話題(笑)のハンコも不要。</p>
<p>私は住基ネット用の電子証明書も登録している。
併せて更新するか尋ねられたので,肯定。
手順としては,職員さんの指示の下,タッチパネルで</p>
<ol>
<li>住基用の暗証番号を入力</li>
<li>(住基用の)署名用電子証明書のパスワードを入力</li>
<li>利用者証明用電子証明書の暗証番号を入力</li>
</ol>
<p>で完了。
券面事項入力補助の暗証番号は使わなかった。
簡単!</p>
<p>次回はまた5年後。
5年後は個人番号カード自体も更新しないといけないので顔写真がいるな。</p>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B00WAMAKZQ?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/61gih7I7ztL._SL160_.jpg" width="120" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B00WAMAKZQ?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">コマンドー (吹替版)</a></dt>
<dd>アーノルド・シュワルツェネッガー (出演), アリッサ・ミラノ (出演), ダン・ヘダヤ (出演), レイ・ドーン・チョン (出演), マーク・L・レスター (監督), スティーブン・E・デ・スーザ (Writer)</dd>
<dd> (Release 2015-04-24)</dd>
<dd>Prime Video</dd>
<dd>B00WAMAKZQ (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="4"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="far fa-star"></i></abbr></dd>
</dl>
<p class="description">あらゆる障害を筋肉で粉砕する! 脳みそをカラッぽにして見れる作品。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2020-10-13">2020-10-13</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- コマンドー -->
GnuPG 2.2.17 リリース: 公開鍵サーバ・アクセスに関する過激な変更あり
tag:text.Baldanders.info,2019-07-10:/release/2019/07/gnupg-2_2_17-is-released/
2019-07-10T12:29:53+00:00
2020-01-05T11:59:50+00:00
今回の変更で公開鍵サーバ上の公開鍵について付帯する電子署名は(自己署名を除いて)捨てられることになった。
Spiegel
https://baldanders.info/profile/
<p>くっそー。
Gmail の野郎が <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> からのアナウンスを迷惑メールとして処理してくれやがったので気づくのが遅れた。</p>
<p><a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> 2.2.17 のリリースである。</p>
<ul>
<li><a href="https://lists.gnupg.org/pipermail/gnupg-announce/2019q3/000439.html">[Announce] GnuPG 2.2.17 released to mitigate attacks on keyservers</a></li>
</ul>
<p>先日紹介した「<a href="https://text.baldanders.info/remark/2019/07/openpgp-certificate-flooding/">OpenPGP 公開鍵サーバにおける公開鍵の汚染問題</a>」を受けて公開鍵サーバからのインポートをかなり制限することにしたようだ。</p>
<p>詳細はこちら。</p>
<figure lang="en">
<blockquote><ul>
<li>gpg: Ignore all key-signatures received from keyservers. This change is required to mitigate a DoS due to keys flooded with faked key-signatures. The old behaviour can be achieved by adding <code>keyserver-options no-self-sigs-only,no-import-clean</code> to your <code>gpg.conf</code>. [#4607]</li>
<li>gpg: If an imported keyblocks is too large to be stored in the keybox (<code>pubring.kbx</code>) do not error out but fallback to an import using the options “<code>self-sigs-only,import-clean</code>”. [#4591]</li>
<li>gpg: New command <code>--locate-external-key</code> which can be used to refresh keys from the Web Key Directory or via other methods configured with <code>--auto-key-locate</code>.</li>
<li>gpg: New import option “<code>self-sigs-only</code>”.</li>
<li>gpg: In <code>--auto-key-retrieve</code> prefer WKD over keyservers. [#4595]</li>
<li>dirmngr: Support the “<code>openpgpkey</code>” subdomain feature from <code>draft-koch-openpgp-webkey-service-07</code>. [#4590].</li>
<li>dirmngr: Add an exception for the “<code>openpgpkey</code>” subdomain to the CSRF protection. [#4603]</li>
<li>dirmngr: Fix endless loop due to http errors 503 and 504. [#4600]</li>
<li>dirmngr: Fix TLS bug during redirection of HKP requests. [#4566]</li>
<li>gpgconf: Fix a race condition when killing components. [#4577]</li>
</ul>
<p>Release-info: <a href="https://dev.gnupg.org/T4606">https://dev.gnupg.org/T4606</a></p></blockquote>
<figcaption><div>via <q><a href="https://lists.gnupg.org/pipermail/gnupg-announce/2019q3/000439.html">GnuPG 2.2.17 released to mitigate attacks on keyservers</a></q></div></figcaption>
</figure>
<p>今回の変更で公開鍵サーバ上の公開鍵について付帯する電子署名は(自己署名を除いて)捨てられることになった。
以前の動作に戻したければ <code>gpg.conf</code> に以下のオプションを追加する。</p>
<pre tabindex="0"><code>keyserver-options no-self-sigs-only,no-import-clean
</code></pre><p>しかし現時点でこれはおすすめできない。</p>
<p>また公開鍵のインポートで <code>--self-sigs-only</code> オプションが使えるようだ。
状況に応じて使い分けるといいだろう。</p>
<p>ちなみに拙作の <a href="https://github.com/spiegel-im-spiegel/gpgpdump" title="spiegel-im-spiegel/gpgpdump: OpenPGP packet visualizer">gpgpdump</a> を使って,公開鍵をインポートする前に鍵の構成をチェックできる。
v0.6.0 から公開鍵サーバ上の公開鍵を直接チェックできるようにしたので上手く使っていただけるとありがたい。</p>
<ul>
<li><a href="https://text.baldanders.info/release/2019/07/gpgpdump-v0_6_0-is-released/">gpgpdump v0.6.0 をリリースした</a></li>
</ul>
<p>後半の WKD (Web Key Directory) は 2019-07-10 現在ドラフト08が出ている。</p>
<ul>
<li><a href="https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07">OpenPGP Web Key Directory draft-koch-openpgp-webkey-service-07</a></li>
<li><a href="https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08">OpenPGP Web Key Directory draft-koch-openpgp-webkey-service-08</a></li>
</ul>
<p>今回の一連を受けて標準化と実装が早まるかもしれない。
私もちょっと検討してみようかな。
OpenPGP のメーリングリストでも議論が行われているんだけどスルーしてたんだよなぁ。</p>
<p>さて <a href="https://www.ubuntu.com/" title="The leading operating system for PCs, IoT devices, servers and the cloud | Ubuntu">Ubuntu</a> が今回のバージョンをちゃんとリリースしてくれるといいんだけど。
しないのなら本気で私的ビルドを<ruby><rb>検討</rb><rp> (</rp><rt>どげんか</rt><rp>) </rp></ruby>せんといけんかもしれん。</p>
<h2>ブックマーク</h2>
<ul>
<li><a href="https://text.baldanders.info/openpgp/openpgp-key-management/">OpenPGP 鍵管理に関する考察</a></li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/4314009071?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51ZRZ62WKCL._SL160_.jpg" width="108" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/4314009071?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号化 プライバシーを救った反乱者たち</a></dt>
<dd>スティーブン・レビー (著), 斉藤 隆央 (翻訳)</dd>
<dd>紀伊國屋書店 2002-02-16</dd>
<dd>単行本</dd>
<dd>4314009071 (ASIN), 9784314009072 (EAN), 4314009071 (ISBN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">20世紀末,暗号技術の世界で何があったのか。知りたかったらこちらを読むべし!</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-03-09">2015-03-09</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号化 プライバシーを救った反乱者たち -->
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t6yHHVwEL._SL160_.jpg" width="113" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号技術入門 第3版 秘密の国のアリス</a></dt>
<dd>結城 浩 (著)</dd>
<dd>SBクリエイティブ 2015-08-25 (Release 2015-09-17)</dd>
<dd>Kindle版</dd>
<dd>B015643CPE (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-09-20">2015-09-20</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号技術入門 第3版 -->
OpenPGP 公開鍵サーバにおける公開鍵の汚染問題
tag:text.Baldanders.info,2019-07-05:/remark/2019/07/openpgp-certificate-flooding/
2019-07-05T14:46:33+00:00
2020-11-29T04:13:22+00:00
新しい OpenPGP 公開鍵サーバや Autocrypt について調査したほうがいいかしらん。
Spiegel
https://baldanders.info/profile/
<p>7pay のセキュリティ事故があまりにバカすぎるのでブログネタにしてやろうかと思っていたが,個人的にもっと重大な案件が出てきたので,先にこちらの話を書くことにする。</p>
<ul>
<li><a href="https://japan.zdnet.com/article/35139514/">PGPのSKSキーサーバーネットワークへの証明書ポイズニング–攻撃を受け開発者らが警鐘 - ZDNet Japan</a></li>
</ul>
<p>かなりヤバいというか「ついにやっちゃったか」って感じの話なのだが,記事の後半に書かれている</p>
<figure>
<blockquote>
<q>キーサーバーはPGPと、PGPプロトコルにおけるユーザー認証の要となるコンポーネントだ</q>
</blockquote>
<figcaption><div><q><a href="https://japan.zdnet.com/article/35139514/">PGPのSKSキーサーバーネットワークへの証明書ポイズニング--攻撃を受け開発者らが警鐘</a></q>より</div></figcaption>
</figure>
<p>というのはかなり言い過ぎである。</p>
<p>というのも,そもそも <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の元祖である <a href="https://tools.ietf.org/html/rfc1991" title="RFC 1991 - PGP Message Exchange Formats">PGP</a> は必ずしも公開鍵サーバを要件としていたわけではなく(<a href="https://www.amazon.co.jp/exec/obidos/ASIN/4900900028/baldandersinf-22/">PGP 本</a>を読めば分かるが,当時はフロッピー運用とか当たり前の時代だった),後継である <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> においてもそのコンセプトが踏襲されているからだ。
<a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の信用モデル(web of trust; 信用の輪)については拙文ながら以下を参考にしてほしい。</p>
<ul>
<li><a href="https://text.baldanders.info/openpgp/openpgp-key-management/">OpenPGP 鍵管理に関する考察</a></li>
</ul>
<p>この信用モデルの下では</p>
<ul>
<li>多くの電子署名が集まっていること</li>
<li>同じ鍵が永続的に使われ続けていること</li>
</ul>
<p>が鍵の信用を高める条件となっている<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup>。
<a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 公開鍵サーバにおいて鍵や署名の追記しかできないのにはちゃんと理由があるのだ。</p>
<p>とは言え <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 公開鍵サーバが鍵運用において大きなウエイトを占めているのは間違いないことで,鍵の所有者が(電子署名や鍵そのものの削除を含めて)制御できないというのはちょっと,いやだいぶ困った事態となっているのも確かである。</p>
<p>たとえば APT などのパッケージ管理ツールでは,パッケージへの電子署名に <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 公開鍵を使うが,鍵のインポートの際に公開鍵サーバを利用するようだ。</p>
<p>この前紹介した <a href="https://text.baldanders.info/remark/2019/04/mono-in-ubuntu/" title="Ubuntu に Mono を導入する
">Mono のインストール</a>でも</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
</span></span></code></pre></div><p>といった感じで鍵サーバから公開鍵をインポートしている<sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup>。</p>
<p>なので,鍵サーバに登録されている公開鍵が汚染されている(可能性がある)というのは拙いのである。</p>
<h2>回避策1: <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 公開鍵サーバを使わない</h2>
<p>今回のリスクを確実に回避したいのであれば <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 公開鍵サーバを使わないのが手っ取り早い。
以下のように,いったんテキストデータとして吐き出して</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg -a --export alice@example.com
</span></span><span class="line"><span class="cl">-----BEGIN PGP PUBLIC KEY BLOCK-----
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">mQENBFofiskBCADjUvPHA3PNscg0K74/Uwxj46+oLsyIy7fYIp/4C4dHejcbbPjx
</span></span><span class="line"><span class="cl">VFeic9wQ4aQFp3VKjYgONgQrRo/9p40Ei1+PtMAV7D6Oy6dxlV8zyCJcSf74ahpB
</span></span><span class="line"><span class="cl">B15GyA7v4uvTf0Py+Ujyt241ik0fXeLEuwt7p4SIbgJnQs1Fb+61wo8UcCFOLJO5
</span></span><span class="line"><span class="cl">An6HjXNgNs6fFoiTad+T4PfaTbRHLfFPkoqmDUKWy40hjWl+Ui0QborXH+PUeUm9
</span></span><span class="line"><span class="cl">vgHbqZzS0QRDGI7rO9AeJ6LweBkP1A2qbDLyexS/F+WUEcY0b76IQM5XH0txwnnl
</span></span><span class="line"><span class="cl">uCPYcQfIGWce3US1GWJhChF9s/bMGVXOEJbvABEBAAG0GUFsaWNlIDxhbGljZUBl
</span></span><span class="line"><span class="cl">eGFtcGxlLmNvbT6JAVQEEwEIAD4CGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AW
</span></span><span class="line"><span class="cl">IQR5/SuZ88YtLTuFC7yTs1CUdYINXQUCWh+LMAUJA8JnZwAKCRCTs1CUdYINXcKT
</span></span><span class="line"><span class="cl">B/4tLFaPRe289GcX91yLJ/yPS0JvvJKyZzjpNqLbKHuQHPEqGromMGlP4LcaGdFL
</span></span><span class="line"><span class="cl">rVZ36W3kVk+75q8JFkld0eRS22vftjz6lA9lyb3W9lU1CayF5s3IsC/Ehj55uaHc
</span></span><span class="line"><span class="cl">OHnp6rl7zEeIdvca6yV0gwySs3j9VPHy58zNrpN/clHoB4Zozy6vCXFMShyLc/wF
</span></span><span class="line"><span class="cl">brPySf/5LP/642Uro92M2lbkIvZpDhZCVG7s7Ilz3BzsTTNMPkPd5yvdGa5lHQzK
</span></span><span class="line"><span class="cl">OmXHaxydOYbEWBgqRGqzEIIoLbEd8KHxJVIVDfcAQCjSWRUjAUSDLpBokGsKoQfp
</span></span><span class="line"><span class="cl">41NjWwjkIsfyJ2tDUeRPGYRbuQENBFofiskBCACzyYfIB+/ZwJBJXw7WMDlEKdnz
</span></span><span class="line"><span class="cl">L4abwVpw9rBGAWGXjaC/cu7l0svNilXyTgZNq4uKddJ6aYjs7of0SaBl20I8aj5G
</span></span><span class="line"><span class="cl">nbw0pG+KkoYhfpZaAZc+bcb+6SprSbAsRhrZ810XNIBUMa8XWsUDn1uv70vGBWBv
</span></span><span class="line"><span class="cl">keKZZ7FJ4kuQe0nTONmvQ4EwFekV+IXT5LwdgmPWF0QR7cO8jqeb6psHYauktuzZ
</span></span><span class="line"><span class="cl">2ul4nMLmLLf/m4DwiCAbEdToBXqRA30KshtgBYYQwL1YkWYgknnAdhHyeu6ybJvv
</span></span><span class="line"><span class="cl">Y57JYzotjFOlnFhtcGITESEWv+pnj0RJUUrlVwLkJhUOKMwL+sbhw0s5+m27ABEB
</span></span><span class="line"><span class="cl">AAGJATwEGAEIACYCGwwWIQR5/SuZ88YtLTuFC7yTs1CUdYINXQUCWh+LhAUJA8Jn
</span></span><span class="line"><span class="cl">uwAKCRCTs1CUdYINXXuvB/9IKK3SLgJ6lOc2Vq73rGYsrDqfjYt5rCDXhjIaFRE7
</span></span><span class="line"><span class="cl">LYmFJcGL5CHJTae438XtAixa+mu6PYG28eknjZs58Cx/bSj9uS6NiLAPCgyTAtvg
</span></span><span class="line"><span class="cl">ao6usECOm9Y0xf2+ZcZ9Uji+wsCAFmxRC9je0yUErVyuyQRqzNtdqytnszoTzvb9
</span></span><span class="line"><span class="cl">iOP8sX/YNrjC83BtZ4Vg3fzAu8qvwbObgSbws5M8TBwIKd4WFTjOtSU6F8aioJ1g
</span></span><span class="line"><span class="cl">mpfd8KGljHkzC0oG8l8fZiTNYqkIMbfyfPpVwsSqsysLKofifFT+mNs79DJdqNFO
</span></span><span class="line"><span class="cl">HA2W4WzekYmWWmgK7J8kXHYkxUJA6VpSmNAKwUKqXbNV
</span></span><span class="line"><span class="cl">=hneF
</span></span><span class="line"><span class="cl">-----END PGP PUBLIC KEY BLOCK-----
</span></span></code></pre></div><p>このテキストデータで運用すればいいのだ。</p>
<p>たとえば私の公開鍵は<a href="https://baldanders.info/pubkeys/" title="OpenPGP 公開鍵リスト | Baldanders.info">本家サイトで公開している</a>が</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --fetch-keys https://baldanders.info/pubkeys/spiegel.asc
</span></span></code></pre></div><p>とすれば簡単に鍵束にインポートできる。</p>
<!--
メールの暗号化や署名検証については [Autocrypt] のような仕組みを使えば鍵サーバを経由せずに鍵のやりとりができるらしい(実はよく知らない)。
ちなみに Thunderbird の [Enigmail] は [Autocrypt] に対応している。
[Autocrypt] についてはちゃんと調べていつか記事にする予定である。
-->
<h2>回避策2: <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 公開鍵サーバ上の公開鍵をいきなりインポートしない</h2>
<p>APT のように <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 公開鍵サーバを使った鍵運用が必須の場合でも,いきなり鍵束にインポートするのではなく,事前に公開鍵をチェックして問題がないか調べたほうがよさそうである。</p>
<p>公開鍵をチェックするのであれば <a href="https://github.com/kazu-yamamoto/pgpdump" title="kazu-yamamoto/pgpdump: A PGP packet visualizer">pgpdump</a> か(手前味噌でナニだが)その <a href="https://golang.org/" title="The Go Programming Language">Go 言語</a>版である <a href="https://github.com/spiegel-im-spiegel/gpgpdump" title="spiegel-im-spiegel/gpgpdump: OpenPGP packet visualizer">gpgpdump</a> を使うことをオススメする。</p>
<p>先ほどの</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
</span></span></code></pre></div><p>であれば</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ wget -O - "http://keyserver.ubuntu.com/pks/lookup?search=0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF&op=get"
</span></span></code></pre></div><p>などとすればとすれば Armor テキストでダウンロードできる。
汚染されている公開鍵であればかなり巨大になっているだろうから,ある程度の判断はできそうである。</p>
<h3>【追記 2019-07-06】 <a href="https://github.com/spiegel-im-spiegel/gpgpdump" title="spiegel-im-spiegel/gpgpdump: OpenPGP packet visualizer">gpgpdump</a> に HKP アクセスモードを追加した</h3>
<p><a href="https://github.com/spiegel-im-spiegel/gpgpdump" title="spiegel-im-spiegel/gpgpdump: OpenPGP packet visualizer">gpgpdump</a> の v0.6.0 をリリースしたが,このバージョンから HKP アクセスモードを追加した。</p>
<ul>
<li><a href="https://text.baldanders.info/release/2019/07/gpgpdump-v0_6_0-is-released/">gpgpdump v0.6.0 をリリースした</a></li>
</ul>
<p>この機能を使えば</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpgpdump hkp --keyserver keyserver.ubuntu.com --port 80 0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF -u
</span></span><span class="line"><span class="cl">Public-Key Packet (tag 6) (269 bytes)
</span></span><span class="line"><span class="cl"> Version: 4 (current)
</span></span><span class="line"><span class="cl"> Public key creation time: 2014-08-04T15:35:03Z
</span></span><span class="line"><span class="cl"> Public-key Algorithm: RSA (Encrypt or Sign) (pub 1)
</span></span><span class="line"><span class="cl"> RSA public modulus n (2048 bits)
</span></span><span class="line"><span class="cl"> RSA public encryption exponent e (17 bits)
</span></span><span class="line"><span class="cl">User ID Packet (tag 13) (58 bytes)
</span></span><span class="line"><span class="cl"> User ID: Xamarin Public Jenkins (auto-signing) <releng@xamarin.com>
</span></span><span class="line"><span class="cl">Signature Packet (tag 2) (312 bytes)
</span></span><span class="line"><span class="cl"> Version: 4 (current)
</span></span><span class="line"><span class="cl"> Signiture Type: Positive certification of a User ID and Public-Key packet (0x13)
</span></span><span class="line"><span class="cl"> Public-key Algorithm: RSA (Encrypt or Sign) (pub 1)
</span></span><span class="line"><span class="cl"> Hash Algorithm: SHA-1 (hash 2)
</span></span><span class="line"><span class="cl"> Hashed Subpacket (34 bytes)
</span></span><span class="line"><span class="cl"> Signature Creation Time (sub 2): 2014-08-04T15:35:03Z
</span></span><span class="line"><span class="cl"> Key Flags (sub 27) (1 bytes)
</span></span><span class="line"><span class="cl"> Flag: This key may be used to certify other keys.
</span></span><span class="line"><span class="cl"> Flag: This key may be used to sign data.
</span></span><span class="line"><span class="cl"> Preferred Symmetric Algorithms (sub 11) (5 bytes)
</span></span><span class="line"><span class="cl"> Symmetric Algorithm: AES with 256-bit key (sym 9)
</span></span><span class="line"><span class="cl"> Symmetric Algorithm: AES with 192-bit key (sym 8)
</span></span><span class="line"><span class="cl"> Symmetric Algorithm: AES with 128-bit key (sym 7)
</span></span><span class="line"><span class="cl"> Symmetric Algorithm: CAST5 (128 bit key, as per) (sym 3)
</span></span><span class="line"><span class="cl"> Symmetric Algorithm: TripleDES (168 bit key derived from 192) (sym 2)
</span></span><span class="line"><span class="cl"> Preferred Hash Algorithms (sub 21) (5 bytes)
</span></span><span class="line"><span class="cl"> Hash Algorithm: SHA2-256 (hash 8)
</span></span><span class="line"><span class="cl"> Hash Algorithm: SHA-1 (hash 2)
</span></span><span class="line"><span class="cl"> Hash Algorithm: SHA2-384 (hash 9)
</span></span><span class="line"><span class="cl"> Hash Algorithm: SHA2-512 (hash 10)
</span></span><span class="line"><span class="cl"> Hash Algorithm: SHA2-224 (hash 11)
</span></span><span class="line"><span class="cl"> Preferred Compression Algorithms (sub 22) (3 bytes)
</span></span><span class="line"><span class="cl"> Compression Algorithm: ZLIB <RFC1950> (comp 2)
</span></span><span class="line"><span class="cl"> Compression Algorithm: BZip2 (comp 3)
</span></span><span class="line"><span class="cl"> Compression Algorithm: ZIP <RFC1951> (comp 1)
</span></span><span class="line"><span class="cl"> Features (sub 30) (1 bytes)
</span></span><span class="line"><span class="cl"> Flag: Modification Detection (packets 18 and 19)
</span></span><span class="line"><span class="cl"> Key Server Preferences (sub 23) (1 bytes)
</span></span><span class="line"><span class="cl"> Flag: No-modify
</span></span><span class="line"><span class="cl"> Unhashed Subpacket (10 bytes)
</span></span><span class="line"><span class="cl"> Issuer (sub 16): 0xa6a19b38d3d831ef
</span></span><span class="line"><span class="cl"> Hash left 2 bytes
</span></span><span class="line"><span class="cl"> 90 e8
</span></span><span class="line"><span class="cl"> RSA signature value m^d mod n (2047 bits)
</span></span><span class="line"><span class="cl">Signature Packet (tag 2) (284 bytes)
</span></span><span class="line"><span class="cl"> Version: 4 (current)
</span></span><span class="line"><span class="cl"> Signiture Type: Generic certification of a User ID and Public-Key packet (0x10)
</span></span><span class="line"><span class="cl"> Public-key Algorithm: RSA (Encrypt or Sign) (pub 1)
</span></span><span class="line"><span class="cl"> Hash Algorithm: SHA-1 (hash 2)
</span></span><span class="line"><span class="cl"> Hashed Subpacket (6 bytes)
</span></span><span class="line"><span class="cl"> Signature Creation Time (sub 2): 2014-09-04T15:26:28Z
</span></span><span class="line"><span class="cl"> Unhashed Subpacket (10 bytes)
</span></span><span class="line"><span class="cl"> Issuer (sub 16): 0xc90f9cb90e1fad0c
</span></span><span class="line"><span class="cl"> Hash left 2 bytes
</span></span><span class="line"><span class="cl"> 9c d7
</span></span><span class="line"><span class="cl"> RSA signature value m^d mod n (2046 bits)
</span></span><span class="line"><span class="cl">Signature Packet (tag 2) (284 bytes)
</span></span><span class="line"><span class="cl"> Version: 4 (current)
</span></span><span class="line"><span class="cl"> Signiture Type: Generic certification of a User ID and Public-Key packet (0x10)
</span></span><span class="line"><span class="cl"> Public-key Algorithm: RSA (Encrypt or Sign) (pub 1)
</span></span><span class="line"><span class="cl"> Hash Algorithm: SHA2-256 (hash 8)
</span></span><span class="line"><span class="cl"> Hashed Subpacket (6 bytes)
</span></span><span class="line"><span class="cl"> Signature Creation Time (sub 2): 2016-12-11T01:14:48Z
</span></span><span class="line"><span class="cl"> Unhashed Subpacket (10 bytes)
</span></span><span class="line"><span class="cl"> Issuer (sub 16): 0x01150a655bbd8102
</span></span><span class="line"><span class="cl"> Hash left 2 bytes
</span></span><span class="line"><span class="cl"> 7f cf
</span></span><span class="line"><span class="cl"> RSA signature value m^d mod n (2048 bits)
</span></span><span class="line"><span class="cl">Public-Subkey Packet (tag 14) (269 bytes)
</span></span><span class="line"><span class="cl"> Version: 4 (current)
</span></span><span class="line"><span class="cl"> Public key creation time: 2014-08-04T15:35:03Z
</span></span><span class="line"><span class="cl"> Public-key Algorithm: RSA (Encrypt or Sign) (pub 1)
</span></span><span class="line"><span class="cl"> RSA public modulus n (2048 bits)
</span></span><span class="line"><span class="cl"> RSA public encryption exponent e (17 bits)
</span></span><span class="line"><span class="cl">Signature Packet (tag 2) (287 bytes)
</span></span><span class="line"><span class="cl"> Version: 4 (current)
</span></span><span class="line"><span class="cl"> Signiture Type: Subkey Binding Signature (0x18)
</span></span><span class="line"><span class="cl"> Public-key Algorithm: RSA (Encrypt or Sign) (pub 1)
</span></span><span class="line"><span class="cl"> Hash Algorithm: SHA-1 (hash 2)
</span></span><span class="line"><span class="cl"> Hashed Subpacket (9 bytes)
</span></span><span class="line"><span class="cl"> Signature Creation Time (sub 2): 2014-08-04T15:35:03Z
</span></span><span class="line"><span class="cl"> Key Flags (sub 27) (1 bytes)
</span></span><span class="line"><span class="cl"> Flag: This key may be used to encrypt communications.
</span></span><span class="line"><span class="cl"> Flag: This key may be used to encrypt storage.
</span></span><span class="line"><span class="cl"> Unhashed Subpacket (10 bytes)
</span></span><span class="line"><span class="cl"> Issuer (sub 16): 0xa6a19b38d3d831ef
</span></span><span class="line"><span class="cl"> Hash left 2 bytes
</span></span><span class="line"><span class="cl"> ac 35
</span></span><span class="line"><span class="cl"> RSA signature value m^d mod n (2048 bits)
</span></span></code></pre></div><p>といった感じに <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 公開鍵サーバ上の公開鍵を直接検査できる。
これなら最悪でも <a href="https://github.com/spiegel-im-spiegel/gpgpdump" title="spiegel-im-spiegel/gpgpdump: OpenPGP packet visualizer">gpgpdump</a> がコケるだけなので <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の鍵束にはダメージがいかないだろう。</p>
<h2>回避策3: <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> 2.2.17 以降を使って電子署名のインポートを拒否する(2019-07-10 追記)</h2>
<p><a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> 2.2.17 から公開鍵サーバ上の公開鍵について付帯する電子署名を(自己署名を除いて)捨てることにしたようだ。</p>
<ul>
<li><a href="https://text.baldanders.info/release/2019/07/gnupg-2_2_17-is-released/">GnuPG 2.2.17 リリース: 公開鍵サーバ・アクセスに関する過激な変更あり</a></li>
</ul>
<p>これなら最悪は免れるかな。
公開鍵の管理の仕方が大幅に変わるかもしれないけど。</p>
<h2>新しい keys.openpgp.org を使う</h2>
<p>今後の話になるだろうが,新しい <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 公開鍵サーバが登場したので,公開鍵の運用をそちらに移行する手もある。</p>
<ul>
<li><a href="https://text.baldanders.info/remark/2019/06/launching-a-new-openpgp-key-server/">新しい OpenPGP 鍵サーバが Launch したらしい</a></li>
</ul>
<p>「まだベータ運用だし,しばらくは様子見かなぁ」と思っていたが,ちょっと前倒しして調査したほうがいいかしらん。</p>
<!-- 先ほどの [Autocrypt] の調査も併せて色々調べてみるつもりである。 -->
<h2>ブックマーク</h2>
<ul>
<li>
<p><a href="https://www.vice.com/en_us/article/8xzj45/someone-is-spamming-and-breaking-a-core-component-of-pgps-ecosystem">Someone Is Spamming and Breaking a Core Component of PGP’s Ecosystem - VICE</a></p>
</li>
<li>
<p><a href="https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f">SKS Keyserver Network Under Attack · GitHub</a></p>
</li>
<li>
<p><a href="https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html">dkg’s blog - OpenPGP Certificate Flooding</a></p>
</li>
<li>
<p><a href="https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html">Impact of SKS keyserver poisoning on Gentoo – Gentoo Linux</a></p>
</li>
<li>
<p><a href="https://text.baldanders.info/openpgp/gnupg-cheat-sheet/">GnuPG チートシート(鍵作成から失効まで)</a></p>
</li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/4900900028?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/5132396FFQL._SL160_.jpg" width="124" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/4900900028?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">PGP―暗号メールと電子署名</a></dt>
<dd>シムソン ガーフィンケル (著), Garfinkel,Simson (原著), ユニテック (翻訳)</dd>
<dd>オライリー・ジャパン 1996-04-01</dd>
<dd>単行本</dd>
<dd>4900900028 (ASIN), 9784900900028 (EAN), 4900900028 (ISBN)</dd>
<dd>評価<abbr class="rating fa-sm" title="3"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="far fa-star"></i> <i class="far fa-star"></i></abbr></dd>
</dl>
<p class="description">良書なのだが,残念ながら内容が古すぎた。 PGP の歴史資料として読むならいいかもしれない。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2014-10-16">2014-10-16</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- PGP―暗号メールと電子署名 -->
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t6yHHVwEL._SL160_.jpg" width="113" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号技術入門 第3版 秘密の国のアリス</a></dt>
<dd>結城 浩 (著)</dd>
<dd>SBクリエイティブ 2015-08-25 (Release 2015-09-17)</dd>
<dd>Kindle版</dd>
<dd>B015643CPE (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-09-20">2015-09-20</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号技術入門 第3版 -->
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/4314009071?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51ZRZ62WKCL._SL160_.jpg" width="108" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/4314009071?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号化 プライバシーを救った反乱者たち</a></dt>
<dd>スティーブン・レビー (著), 斉藤 隆央 (翻訳)</dd>
<dd>紀伊國屋書店 2002-02-16</dd>
<dd>単行本</dd>
<dd>4314009071 (ASIN), 9784314009072 (EAN), 4314009071 (ISBN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">20世紀末,暗号技術の世界で何があったのか。知りたかったらこちらを読むべし!</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-03-09">2015-03-09</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号化 プライバシーを救った反乱者たち -->
<div class="footnotes" role="doc-endnotes">
<hr>
<ol>
<li id="fn:1">
<p>そういう意味で <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 公開鍵への電子署名は厳密な「証明(certification)」というよりは小切手の裏書きのようなものを連想してもらうのがいいだろう。つまり今回の「公開鍵の汚染問題」は「裏書き spam」と考えると分かりやすい。 <a href="#fnref:1" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:2">
<p>ちなみに <code>--keyserver</code> とか <code>--recv-keys</code> とかは <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> のオプションである。おそらくこれらのオプションをそのまま <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> に引き渡しているのだろう。 <a href="#fnref:2" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
</ol>
</div>
新しい OpenPGP 鍵サーバが Launch したらしい
tag:text.Baldanders.info,2019-06-13:/remark/2019/06/launching-a-new-openpgp-key-server/
2019-06-13T13:19:09+00:00
2020-01-05T11:59:50+00:00
これで思い出すのが,かつての OpenPKSD だが,今回の keys.openpgp.org がその二の舞にならないことを祈るばかりである。
Spiegel
https://baldanders.info/profile/
<p><a href="https://www.ietf.org/mailman/listinfo/openpgp">OpenPGP のメーリングリスト</a>より。</p>
<ul>
<li><a href="https://mailarchive.ietf.org/arch/msg/openpgp/1cQeIV8s81lhwG_FQtMuc2JbRSk">Launching a new keyserver on keys.openpgp.org!</a></li>
<li><a href="https://keys.openpgp.org/about/news#2019-06-12-launch">Launching a new keyserver! - keys.openpgp.org</a></li>
<li><a href="https://gitlab.com/sequoia-pgp/hagrid">sequoia-pgp / hagrid · GitLab</a></li>
</ul>
<figure lang="en">
<blockquote><ul>
<li>Fast and reliable. No wait times, no downtimes, no inconsistencies.</li>
<li>Precise. Searches return only a single key, which allows for easy key discovery.</li>
<li>Validating. Identities are only published with consent, while non-identity information is freely distributed.</li>
<li>Deletable. Users can delete personal information with a simple e-mail confirmation.</li>
<li>Built on Rust, powered by <a href="https://sequoia-pgp.org/">Sequoia PGP</a> - free and open source, running AGPLv3.</li>
</ul>
</blockquote>
<figcaption><div>via <q><a href="https://keys.openpgp.org/about/news#2019-06-12-launch">Launching a new keyserver!</a></q></div></figcaption>
</figure>
<p>ほほう。
Rust ベースなのか。
面白いな。</p>
<p>現行の <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 鍵サーバ同士は peer-to-peer で同期しているが,新しい <a href="https://keys.openpgp.org">keys.openpgp.org</a> はこれらとは別のネットワークを形成するようだ。</p>
<figure lang="en">
<blockquote>
<q>We created keys.openpgp.org to provide an alternative to the SKS Keyserver pool, which is the default in many applications today. This distributed network of keyservers has been struggling with <a href="https://medium.com/@mdrahony/are-sks-keyservers-safe-do-we-need-them-7056b495101c">abuse</a>, <a href="https://en.wikipedia.org/wiki/Key_server_(cryptographic)#Problems_with_keyservers">performance</a>, as well as <a href="http://www.openwall.com/lists/oss-security/2017/12/10/1">privacy issues</a>, and more recently also <a href="http://nongnu.13855.n7.nabble.com/SKS-apocalypse-mitigation-td228252.html">GDPR</a> compliance questions. Kristian Fiskerstrand has done a stellar job maintaining the pool for <a href="https://blog.sumptuouscapital.com/2016/12/10-year-anniversary-for-sks-keyservers-net/">more than ten years</a>, but at this point development activity seems to have <a href="https://bitbucket.org/skskeyserver/sks-keyserver/pull-requests/60/clean-build-with-405">mostly ceased</a>.<br>
We thought it time to consider a fresh approach to solve these problems.</q>
</blockquote>
<figcaption><div>via <q><a href="https://keys.openpgp.org/about/news#2019-06-12-launch">Launching a new keyserver!</a></q></div></figcaption>
</figure>
<p>さらに</p>
<figure lang="en">
<blockquote>
<q>The keys.openpgp.org keysever will receive first-party support in upcoming releases of <a href="https://enigmail.net/">Enigmail</a> for Thunderbird, as well as <a href="https://play.google.com/store/apps/details?id=org.sufficientlysecure.keychain&hl=en">OpenKeychain</a> on Android. This means users of those implementations will benefit from the faster response times, and improved key discovery by e-mail address. We hope that this will also give us some momentum to build this project into a bigger community effort. </q>
</blockquote>
<figcaption><div>via <q><a href="https://keys.openpgp.org/about/news#2019-06-12-launch">Launching a new keyserver!</a></q></div></figcaption>
</figure>
<p>ということで <a href="https://enigmail.net/">Enigmail</a> や <a href="https://play.google.com/store/apps/details?id=org.sufficientlysecure.keychain" title="OpenKeychain: Easy PGP - Google Play">OpenKeychain</a> と連携するのであれば期待できそうな感じである。
ただし,いまのところ <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> との相性がイマイチのようなので,もう少し様子を見たいところではある。</p>
<p>これで思い出すのが,かつての <a href="https://www.ipa.go.jp/security/fy16/development/openPKSD/" title="信頼できるOpenPGP公開鍵を提供する公開鍵サーバOpenPKSD Trusted Keyserver:IPA 独立行政法人 情報処理推進機構">OpenPKSD</a> だが,日本主導でフル Ruby で組まれていて割と期待してたんだが,世界的にはあまり注目されないまま閉鎖されたんだよなぁ。
今回の <a href="https://keys.openpgp.org">keys.openpgp.org</a> がそうならないことを祈るばかりである。</p>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t6yHHVwEL._SL160_.jpg" width="113" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号技術入門 第3版 秘密の国のアリス</a></dt>
<dd>結城 浩 (著)</dd>
<dd>SBクリエイティブ 2015-08-25 (Release 2015-09-17)</dd>
<dd>Kindle版</dd>
<dd>B015643CPE (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-09-20">2015-09-20</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号技術入門 第3版 -->
OpenPGP の電子署名は「ユーザーの身元を保証し」ない
tag:text.Baldanders.info,2019-03-21:/openpgp/web-of-trust/
2019-03-20T15:28:40+00:00
2022-03-27T03:30:25+00:00
つまり公開鍵や電子署名で「ユーザーの身元を保証」するのではなく「身元の保証されたユーザ」同士で鍵と電子署名を運用するのである。
Spiegel
https://baldanders.info/profile/
<p>重箱の隅を突っつくような内容で申し訳ないのだが</p>
<ul>
<li><a href="https://forest.watch.impress.co.jp/docs/news/1175019.html">「GitKraken 5.0」がリリース ~GPGコミットや“Interactive Rebase”をサポート - 窓の杜</a></li>
</ul>
<p>という記事で</p>
<figure>
<blockquote>
<q>メジャーアップデートとなる本バージョンでは、“GNU Privacy Guard (GPG)”による署名付きのコミットがサポートされた。ユーザーの身元を保証し、他のユーザーによるなりすましを防止することができる。</q>
</blockquote>
<figcaption><div><q><a href="https://forest.watch.impress.co.jp/docs/news/1175019.html">「GitKraken 5.0」がリリース ~GPGコミットや“Interactive Rebase”をサポート</a></q>より</div></figcaption>
</figure>
<p>などと書いてあって「それはちゃうやろ」という話。</p>
<h2>暗号機能の4要素</h2>
<p>昔からよく言われる暗号機能の4要件は以下の通り。</p>
<ul>
<li>機密性(Confidentiality)</li>
<li>完全性(Integrity)</li>
<li>認証(Authentication)</li>
<li>否認防止(Non-repudiation)</li>
</ul>
<p>このうちデータへの電子署名では主に完全性と否認防止を行う。
否認防止という言葉はちょっと耳慣れないかもしれないが,要するに「あなたはこのデータに署名した」という事実を否認することが出来ない,という意味である<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup>。</p>
<p>これらを達成するためには電子署名に使う公開鍵が鍵オーナーと正しく紐付いている必要がある<sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup>。
おそらく最初の記事は「公開鍵が鍵オーナーと正しく紐付いている」という前提で「ユーザーの身元を保証」などと書いているのかもしれないが,話はそう簡単ではないのだ。</p>
<h2>公開鍵基盤</h2>
<h3>X.509</h3>
<p>「公開鍵が鍵オーナーと正しく紐付いている」ことを証明するために必要なのが「公開鍵基盤(Public-Key Infrastructure; PKI)」である。
公開鍵基盤として最も有名なのは HTTPS 接続で使われている X.509 であろう。
X.509 の「信用モデル(trust model)」では hierarchical な「認証局(Certification Authority; CA)」を構成し,その認証局が公開鍵を証明することで成り立っている。</p>
<p>でも実は認証局が証明しているのは「公開鍵が鍵オーナーと正しく紐付いている」ことだけで,鍵オーナーの「身元を保証」しているわけではない。</p>
<p>そこで HTTPS には <a href="https://baldanders.info/blog/000277/" title="Extended Validation SSL — Baldanders.info">EV SSL (Extended Validation SSL) なる奇っ怪な仕組み</a>が組み込まれた。
これは鍵オーナーの「身元を保証」するための仕組みで,鍵オーナーは認証局に対して自身の身元を証明するものを提出し認証局は公開鍵の管理をより厳格に行う,ということらしい。</p>
<p>正直に言って「屋上屋を架す」仕組みであり認証局の責務を逸脱していると思うのだが,まぁ深くは突っ込むまい。</p>
<h3>Web of Trust</h3>
<p>これに対して PGP/<a href="http://openpgp.org/">OpenPGP</a> が伝統的に執っている信用モデルは「信用の輪(web of trust)」と呼ばれている。</p>
<p>これは要するに「友達の友達は友達」というやつで,ユーザ同士がお互いの鍵を相互に認証することで信用を構成する仕組みである。</p>
<p>何故 PGP/<a href="http://openpgp.org/">OpenPGP</a> が X.509 のような「権威による認証」を採用しなかったかというと,それは PGP の出自に関係がある。
PGP の作者である Phil Zimmermann は,当時は反核運動家であり国家等の「権威」に依らない信用モデルを必要としていたと言われている<sup id="fnref:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup>。</p>
<p>OpenPGP は名前だけならどんな鍵でも作れる。
たとえば Bitcoin の作者と言われる Satoshi Nakamoto の公開鍵は<a href="https://text.baldanders.info/remark/2016/05/openpgp-key-of-satoshi-nakamoto/">公開鍵サーバを探せば簡単に見つかる</a>が,それが「あの」 Satoshi Nakamoto 本人であると示す証拠は(少なくとも公開鍵自体には)存在しない。
OpenPGP 公開鍵やその電子署名で赤の他人の「身元を保証」することは出来ないのだ。</p>
<h2>Git を中心としたチーム運営に <a href="http://openpgp.org/">OpenPGP</a> を利用する</h2>
<p>じゃあ git commit で OpenPGP 署名を付与することにどんな意義があるかというと,それはチーム運営で威力を発揮する。
つまり公開鍵や電子署名で「ユーザーの身元を保証」するのではなく「身元の保証されたユーザ」同士で鍵と電子署名を運用するのである。
これでチーム以外からのなりすまし commit を検知(防止ではない<sup id="fnref:4"><a href="#fn:4" class="footnote-ref" role="doc-noteref">4</a></sup>)しやすくなる。</p>
<p>この辺について詳しくは,拙文「<a href="https://text.baldanders.info/openpgp/openpgp-key-management/">OpenPGP 鍵管理に関する考察</a>」を書いたので興味があれば参照してほしい。</p>
<p>また GitHub のようにアカウントと公開鍵を紐つけることによってサービス内における強力なポートフォリオとして機能している点は見逃せないだろう。
GitHub 上の<ruby><rb>活動</rb><rp> (</rp><rt>contribution</rt><rp>) </rp></ruby>がそのまま「エンジニアとしてのユーザ」の身元を保証しているわけだ。</p>
<p>ホンマ git ってよく出来たシステムだよなぁ。</p>
<h2>ブックマーク</h2>
<ul>
<li>
<p><a href="https://text.baldanders.info/openpgp/git-commit-with-openpgp-signature/">Git Commit で OpenPGP 署名を行う</a></p>
</li>
<li>
<p><a href="https://baldanders.info/spiegel/cc-license/">わかる! OpenPGP 暗号 — Baldanders.info</a></p>
</li>
<li>
<p><a href="https://github.com/goark/gpgpdump">goark/gpgpdump: OpenPGP packet visualizer</a> : OpenPGP 鍵や電子署名のダンプには拙作をどうぞ(宣伝<code>w</code>)</p>
</li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/4314009071?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51ZRZ62WKCL._SL160_.jpg" width="108" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/4314009071?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号化 プライバシーを救った反乱者たち</a></dt>
<dd>スティーブン・レビー (著), 斉藤 隆央 (翻訳)</dd>
<dd>紀伊國屋書店 2002-02-16</dd>
<dd>単行本</dd>
<dd>4314009071 (ASIN), 9784314009072 (EAN), 4314009071 (ISBN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">20世紀末,暗号技術の世界で何があったのか。知りたかったらこちらを読むべし!</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-03-09">2015-03-09</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号化 プライバシーを救った反乱者たち -->
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/4900900028?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/5132396FFQL._SL160_.jpg" width="124" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/4900900028?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">PGP―暗号メールと電子署名</a></dt>
<dd>シムソン ガーフィンケル (著), Garfinkel,Simson (原著), ユニテック (翻訳)</dd>
<dd>オライリー・ジャパン 1996-04-01</dd>
<dd>単行本</dd>
<dd>4900900028 (ASIN), 9784900900028 (EAN), 4900900028 (ISBN)</dd>
<dd>評価<abbr class="rating fa-sm" title="3"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="far fa-star"></i> <i class="far fa-star"></i></abbr></dd>
</dl>
<p class="description">良書なのだが,残念ながら内容が古すぎた。 PGP の歴史資料として読むならいいかもしれない。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2014-10-16">2014-10-16</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- PGP―暗号メールと電子署名 -->
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t6yHHVwEL._SL160_.jpg" width="113" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号技術入門 第3版 秘密の国のアリス</a></dt>
<dd>結城 浩 (著)</dd>
<dd>SBクリエイティブ 2015-08-25 (Release 2015-09-17)</dd>
<dd>Kindle版</dd>
<dd>B015643CPE (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-09-20">2015-09-20</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号技術入門 第3版 -->
<div class="footnotes" role="doc-endnotes">
<hr>
<ol>
<li id="fn:1">
<p>メッセージング・システムを含む暗号通信においては「否認防止」よりむしろ「否認可能 (Deniability)」が要求される場合がある。詳しくは拙文「<a href="https://baldanders.info/blog/000787/" title="OTR over XMPP — Baldanders.info">OTR over XMPP</a>」を参考にどうぞ。 <a href="#fnref:1" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:2">
<p>たとえば Bitcoin/Blockchain は公開鍵と鍵オーナーとの紐づけを行わない。元帳である Blockchain に記載された取引自体は改竄もなく正しいとしても誰がそれを行ったかを証明する術がない。証明するためには別の仕組みが必要となる。あるいは Bitcoin/Blockchain は「信用」を極力排除することでシステム自体の「正しさ」を担保しているとも言える。 <a href="#fnref:2" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:3">
<p>本当のことろ,作者である Phil Zimmermann がどこまで企図していたのかは知らないが, PGP の登場によって暗号は初めて(国家や大企業のものではなく)一般の人も「使える」ものになったことは確かである。なお <a href="http://openpgp.org/">OpenPGP</a> 実装のひとつである <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> では伝統的な「信用の輪」以外にも X.509 の信用モデルや <a href="https://en.wikipedia.org/wiki/Trust_on_first_use">TOFU (Trust On First Use)</a> と呼ばれる信用モデルもサポートしている。 <a href="#fnref:3" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:4">
<p>なりすましの防止はできなくとも,きちんと鍵と電子署名を運用しているのであれば,抑止にはなるだろう。 <a href="#fnref:4" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
</ol>
</div>
「仮想通貨」と公開鍵基盤
tag:text.Baldanders.info,2018-02-05:/remark/2018/02/blockchain-and-pki/
2018-02-05T10:10:06+00:00
2024-01-26T21:38:55+00:00
Bitcoin が気にするのは Blockchain に記載されるアドレスの一貫性と無矛盾性である。今回はこの部分についてもう少し詳しく書いてみる。
Spiegel
https://baldanders.info/profile/
<p>Twitter で見かけた記事。</p>
<ul>
<li><a href="https://medium.com/@ShinichiroMatsuo/-cde3f8ffa0e4">Satoshiが注意深く設定した世界の境界線 – Shin’ichiro Matsuo – Medium</a></li>
</ul>
<p>Satoshi Nakamoto 氏の論文を引いていてかなり面白い内容だと思うが,言いたいことは単純で,私がこれまで<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">述べてきた</a>通り</p>
<ul>
<li>Bitcoin のアドレスの帰属先について Bitcoin/Blockchain は関知しない。Bitcoin が気にするのは Blockchain に記載されるアドレスの一貫性と無矛盾性である。アドレスの証明が必要な場合は外部の PKI を利用するか新たに組み込む必要がある</li>
</ul>
<p>ということに尽きる。</p>
<p>今回はこの部分についてもう少し詳しく書いてみる。</p>
<h2>まずは定義から</h2>
<p>Blockchain もしくは Blockchain に準ずる技術を用い,価値可換なトークンによって取引を行うシステムを括弧書きで<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>または「<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>システム」と命名する。
この時の「価値可換なトークン」を「コイン」と命名する。
コインは量で表すことができるものとする。</p>
<p>また<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>システムで発生する取引を記録する追記型データベースを「元帳」と命名する。
もちろん元帳は「Blockchain もしくは Blockchain に準ずる技術」を用いて実装されているわけだ。</p>
<p>ここで,ある<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>システム上でユーザ $A$ からユーザ $B$ へコインを移転<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> する「取引」を考える。</p>
<ul>
<li>「ある<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>システム」を $COIN$ とする</li>
<li>取引を $T$ とし,取引の際に移転するコインの量を $c$ とする</li>
<li>$A$ が持つ<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>のアドレスを $a$ とし, $B$ が持つ<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>のアドレスを $b$ とする</li>
</ul>
<p>このときの取引全体を示す図式<sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup> を以下のように記述してみる。</p>
<figure>
<blockquote>
\[
COIN : A[a] \xrightarrow{T(c)} B[b]
\]
</blockquote></figure>
<p>このとき取引 $T$ を元帳に追記する内容は</p>
<figure>
<blockquote>
\[
a \xrightarrow{c} b
\]
</blockquote></figure>
<p>であり,取引関係者である $A$ や $B$ は一切登場しないのがポイントである。</p>
<h2><a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>はアドレスの帰属先を証明(Certificate)しない</h2>
<p><a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>は $a$ の帰属先が $A$ であること,あるいは $b$ の帰属先が $B$ であることを証明しないし証明できない。
もう少し厳密にいうなら「<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>はアドレスの帰属先を証明する責務を負わない」と言える。</p>
<p>このことが何をもたらすか,いくつかシナリオを考えてみよう。</p>
<ul>
<li>$a$ の帰属先が $A$ であると証明できない
<ul>
<li>$B$ は入金 $c$ を $A$ によるものではないと主張できる。 $B$ は $A$ からの入金を否認し $A$ に尚も $c$ を請求するかもしれない</li>
<li>$a$ は別の誰か(たとえば $E$)に乗っ取られているかもしれない。これにより $B$ は取引不成立とみなし $A$ に何らかのペナルティを課すかもしれない \[ COIN : E[a] \xrightarrow{T( c )} B[b] \]</li>
</ul>
</li>
<li>$b$ の帰属先が $B$ であると証明できない
<ul>
<li>$B$ は $b$ が自身に帰属しないと主張できる。これにより $B$ は $A$ からの入金を否認できる</li>
<li>$b$ は別の誰かに乗っ取られているかもしれない。これにより $A$ は取引不成立とみなして出金を拒否した上で $B$ に何らかのペナルティを課すかもしれない(出金した $c$ を上回る量の賠償請求を行うなど) \[ COIN : A[a] \xrightarrow{T( c )} E[b] \]</li>
</ul>
</li>
</ul>
<p>Coincheck 事例の事実関係は(今のところ)よく分かってない部分もあるが,知らない誰かがアドレスを乗っ取って知らない誰かへ「流出」したということであれば</p>
<figure>
<blockquote>
\[
COIN : E[a] \xrightarrow{T(c)} E[b]
\]
</blockquote></figure>
<p>という図式も成り立つ。</p>
<p>しかし実態がどのようなものであれ<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>の元帳には $a \xrightarrow{c} b$ という記録が事実として残るのみで,それが望んだ取引なのか何らかの不正を含んでいるのかといった点について<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>は一切関知しない。</p>
<h2><a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>は P2P を前提とする</h2>
<p>アドレスの帰属先を証明できないというのは実際の取引において致命的な問題となるが,それでもそれなりにまわっているのは<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>がユーザ同士の P2P (peer-to-peer) な関係を前提にしているからである。
つまり「$a$ の帰属先は $A$ である」であり「$b$ の帰属先は $B$ である」であることを $A,B$ 相互に「信用」していることが取引の前提になっている。</p>
<p>しかし,見知った者同士の取引ならともかく,不特定の誰かを何の担保もなく「信用」するのは無理だし,その「信用」そのものを数学的に示す方法は存在しない。
存在しないのであれば,それに代わる「運用でカバー」するしかない。</p>
<p>この「運用」のロジックのことを「信用モデル(trust model)」と呼ぶ。
<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>自体はアドレスに対する信用モデルを持たないが,<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>を利用するサービスが何らかの信用モデルと組み合わせることによりアドレスの帰属先を証明することが可能になる。
また,出来のよい信用モデルを導入することにより不正取引を働くインセンティブが低下することも期待できるだろう。</p>
<p>おそらく<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>を利用するユーザの多くはウォレット・サービスや通貨交換所が信用モデルを組み込むことを期待しているんじゃないかと思うが(投機目的で<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>を運用している人はどうでもいいと思ってるかも知れない),実際にそれらのサービスがアドレスをどうやって「運用」してるのかは(私は現在の<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>への興味が薄いので)知らない。</p>
<h2>公開鍵基盤の信用モデル</h2>
<p>ここで少し目先を変えて公開鍵基盤(Public Key Infrastructure; PKI)の信用モデルを2つほど紹介してみる。
公開鍵基盤というのは公開鍵が誰に帰属するかをサービスを横断して証明するための技術基盤である。</p>
<p>なぜ公開鍵基盤かというと,公開鍵を使った暗号通信の要件が<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>による取引の要件によく似ていると考えられるからだ。
公開鍵を使った暗号通信には以下の4つの要件がある。</p>
<ol>
<li>機密性(Confidentiality)</li>
<li>完全性(Integrity)</li>
<li>認証(Authentication)</li>
<li>否認防止(Non-repudiation)</li>
</ol>
<p>暗号なので1番目は言わずもがなだが,2番目は電子署名によって達成できる。
そして3番目を達成する手段として公開鍵基盤がある。</p>
<p>ちなみに2番目と3番目が達成できれば4番目も達成可能なのだが,否認防止の重要性は前節までを見ればお分かりいただけるだろう。</p>
<h3>X.509 の信用モデル</h3>
<p>典型的な hierarchical PKI として有名なのが X.509 である。
Web の HTTPS 通信で必要な「電子証明書」は X.509 下で運用されている。</p>
<p>X.509 では認証局(Certification Authority; CA)が公開鍵(の帰属先)を証明する電子証明書を発行する。
電子証明書は具体的には,ユーザの公開鍵に対して認証局の鍵で電子署名を付与したものである。
では,認証局の鍵はどうやって証明するかというと,さらに上位の認証局が証明する。
ただし最上位のルート認証局は誰も証明してくれない(自己証明のみ)。</p>
<figure style='margin:0 auto;text-align:center;'>
<div class="mermaid">
graph TD
CA1["root CA"]-- Digital Sign -->CA2
CA1-- Digital Sign -->CA3
CA2-- Digital Sign -->Aa(("A[a]"))
CA3-- Digital Sign -->Bb(("B[b]"))
</div></figure>
<p>X.509 は「認証局は信用できる」という前提に立った信用モデルと言える。
言い方を変えると,ある認証局が信用できるのであれば配下の認証局やユーザは総て信用できる。</p>
<p>X.509 は大規模かつ安定的な運用に向いているが,いったん認証局の信用が崩れると配下の認証局やユーザの信用が一気に崩れることになる。
そのため,認証局,特にルート認証局では高いセキュリティが要求される。</p>
<h3><a href="http://openpgp.org/">OpenPGP</a> の信用モデル</h3>
<p><a href="http://openpgp.org/">OpenPGP</a> における典型的な信用モデルは「信用の輪(web of trust)」と呼ばれている<sup id="fnref:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup>。
信用の輪はユーザ間の P2P な関係がベースになっている。</p>
<p>信用の輪ではユーザ同士がお互いの公開鍵に電子署名を付与する。
たとえば $A$ と $B$ に面識があるなら,相互に電子署名を付与することができる。</p>
<figure style='margin:0 auto;text-align:center;'>
<div class="mermaid">
graph LR
Aa(("A[a]"))
Bb(("B[b]"))
Aa-- Digital Sign -->Bb
Bb-- Digital Sign -->Aa
</div></figure>
<p>ここで3人目の $D$ に登場してもらおう。
$B$ と $D$ は面識があって電子署名を交わしているが, $A$ と $D$ は面識がないものとする。</p>
<figure style='margin:0 auto;text-align:center;'>
<div class="mermaid">
graph LR
Aa(("A[a]"))
Bb(("B[b]"))
Dd(("D[d]"))
Aa-- Digital Sign -->Bb
Bb-- Digital Sign -->Aa
Bb-- Digital Sign -->Dd
Dd-- Digital Sign -->Bb
</div></figure>
<p>この場合でも $A$ と $B$ との関係, $B$ と $D$ との関係をもとに $A$ から見て $D$ も信用できるとみなすのだ。</p>
<figure style='margin:0 auto;text-align:center;'>
<div class="mermaid">
graph LR
Aa(("A[a]"))
Bb(("B[b]"))
Dd(("D[d]"))
Aa-- Digital Sign -->Bb
Aa-. validate! .->Dd
Aa-. trust .->Bb
Bb-- Digital Sign -->Aa
Bb-- Digital Sign -->Dd
Bb-. trust .->Dd
Dd-- Digital Sign -->Bb
</div></figure>
<p>信用の輪はコミュニティ内のアドホックな鍵管理に向いているが,全く関係のない第3者を証明するのは難しい。</p>
<h3>X.509 と <a href="http://openpgp.org/">OpenPGP</a></h3>
<p>山根信二さん等の「<span><a href="https://baldanders.info/spiegel/pgpdump/PGP-001.pdf">OpenPGPとPKI <sup><i class="far fa-file-pdf"></i></sup></a></span>」では X.509 と OpenPGP の PKI の比較を行っている<sup id="fnref:4"><a href="#fn:4" class="footnote-ref" role="doc-noteref">4</a></sup>。
以下に比較表を示す。</p>
<table>
<thead>
<tr>
<th style="text-align:right">特徴</th>
<th>X.509</th>
<th>OpenPGP</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:right">PKI の形態</td>
<td>hierarchical PKI</td>
<td>trust-file PKI</td>
</tr>
<tr>
<td style="text-align:right">公開鍵の認証者</td>
<td>専門機関(CA)</td>
<td>各ユーザ</td>
</tr>
<tr>
<td style="text-align:right">信頼点</td>
<td>ルート CA</td>
<td>利用者自身(面識)</td>
</tr>
<tr>
<td style="text-align:right">認証の連鎖構造</td>
<td>ツリー型</td>
<td>ユーザ中心型</td>
</tr>
<tr>
<td style="text-align:right">認証者を認証する根拠</td>
<td>利用者による選択</td>
<td>利用者自身</td>
</tr>
<tr>
<td style="text-align:right">証明書の破棄と管理</td>
<td>あり</td>
<td>不完全</td>
</tr>
<tr>
<td style="text-align:right">コスト</td>
<td>高い</td>
<td>低い</td>
</tr>
</tbody>
</table>
<p>X.509 と <a href="http://openpgp.org/">OpenPGP</a> の信用モデルはコンセプトが直交しているためどちらが正解とは言えない。
また相互補完的に運用することも可能である。</p>
<h2><a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>の信用モデルは?</h2>
<p><a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>のアドレスの運用についても,おそらく正解はひとつではなく,さまざまな信用モデルがありうると思う。
また信用モデルを<a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>システム自体に埋め込むのか周辺の(ウォレットや交換所などの)サービスで提供するのかというのも議論の余地があると思う。</p>
<p><a href="https://text.baldanders.info/remark/2018/01/cryptocurrency-are-not-crypto/" title="「暗号通貨」ってゆーな!">「仮想通貨」</a>が単なる投機物件ではなく generative な経済活動の技術基盤として生き残っていくことを期待したい。</p>
<h2>ブックマーク</h2>
<ul>
<li><a href="https://text.baldanders.info/openpgp/openpgp-key-management/">OpenPGP 鍵管理に関する考察</a></li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t6yHHVwEL._SL160_.jpg" width="113" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号技術入門 第3版 秘密の国のアリス</a></dt>
<dd>結城 浩 (著)</dd>
<dd>SBクリエイティブ 2015-08-25 (Release 2015-09-17)</dd>
<dd>Kindle版</dd>
<dd>B015643CPE (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-09-20">2015-09-20</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号技術入門 第3版 -->
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B00FONW2V8?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51AT2LqRIsL._SL160_.jpg" width="116" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B00FONW2V8?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">UNDERGROUND MARKET ヒステリアン・ケース</a></dt>
<dd>藤井太洋 (著)</dd>
<dd>朝日新聞出版 2013-11-07 (Release 2013-10-25)</dd>
<dd>Kindle版</dd>
<dd>B00FONW2V8 (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">日本で「仮想通貨」が流行る前に登場した傑作。つかエンジニアは全員「UNDERGROUND MARKET」シリーズを読め!</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2016-01-07">2016-01-07</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- UNDERGROUND MARKET ヒステリアン・ケース -->
<div class="footnotes" role="doc-endnotes">
<hr>
<ol>
<li id="fn:1">
<p>$A$ から見ると $B$ への「出金」, $B$ からみると $A$ からの「入金」と言える。 <a href="#fnref:1" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:2">
<p>数式じゃなくて図式。数式記号を使ってるけどあくまで図式と言い張ってみる。 <a href="#fnref:2" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:3">
<p><a href="http://openpgp.org/">OpenPGP</a> の実装である <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> では信用の輪以外にも <a href="https://en.wikipedia.org/wiki/Trust_on_first_use" title="Trust on first use - Wikipedia">TOFU (Trust On First Use)</a> などの信用モデルを実装している(参考: “<span><a href="#ZgotmplZ">TOFU for OpenPGP <sup><i class="far fa-file-pdf"></i></sup></a></span>”)。 <a href="#fnref:3" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:4">
<p>この論文は2002年に旧 OpenPKSD.org で公開されたが,サイトそのものが消失したため <a href="https://web.archive.org/web/20110907063003/http://www.openpksd.org/">Internet Archive</a> からサルベージした。 <a href="#fnref:4" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
</ol>
</div>
OpenPGP 鍵管理に関する考察
tag:text.Baldanders.info,2017-12-01:/openpgp/openpgp-key-management/
2017-12-01T08:51:59+00:00
2020-01-05T11:59:50+00:00
OpenPGP 鍵の管理について考えてみるテスト。
Spiegel
https://baldanders.info/profile/
<p>たまたま以下の記事を見かけたのだが</p>
<ul>
<li><a href="https://qiita.com/moutend/items/5c22d6e57a74845578f6">gpg (GNU Privacy Guard)の使い方 - Qiita</a></li>
</ul>
<p>このやり方も良さそうだけど,もう少し簡単に運用できないか考えてみる。
なお <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の鍵管理は目的別にアドホック(ad hoc)な運用も可能なので「これ!」という正解はない。
自分にあったやり方を考えるのも面白いと思う。</p>
<h2><a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の信用モデル</h2>
<p>鍵の管理について考える前に <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の信用モデルについておさらいしておこう。</p>
<p>最初の登場人物は Alice と Bob。
2人はそれぞれ <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 鍵を持っていて,これを使って秘密のやり取りをしようと考えている。
持っている鍵が信用できることを証明するために,お互い相手の公開鍵に自身の鍵で電子署名を施した。</p>
<figure style='margin:0 auto;text-align:center;'>
<div class="mermaid">
graph LR
Alice["Alice's Public Key"]
Bob["Bob's Public Key"]
Alice-- Digital Sign -->Bob
Bob-- Digital Sign -->Alice
</div></figure>
<p>鍵に施されている電子署名を確認することでコンテンツに対する暗号文や電子署名が正しい鍵で行われていることが証明できるわけだ。
これが <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の基本。
公開鍵への電子署名を使って peer-to-peer で信用関係を結ぶ<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup>。</p>
<p>ここで3人目の人物 Chris に登場してもらおう。
Bob と Chris は面識があり既にお互いの公開鍵で電子署名を交わしている。
しかし Alice と Chris は面識がなく電子署名を交わす機会がないとする。
Alice から見て Chris の鍵は信用できるだろうか?</p>
<p>(念のために言うと,ここで言う「信用」は「あなたは人として信用できる」の信用ではなく「この鍵は正しく本人のものであると信用できる」の信用である)</p>
<figure style='margin:0 auto;text-align:center;'>
<div class="mermaid">
graph LR
Alice["Alice's Public Key"]
Bob["Bob's Public Key"]
Chris["Chris's Public Key"]
Alice-- Digital Sign -->Bob
Alice-. trust? .->Chris
Bob-- Digital Sign -->Alice
Bob-- Digital Sign -->Chris
Chris-- Digital Sign -->Bob
</div></figure>
<p>まず Alice から見て直接電子署名を交わした Bob の鍵が信用できるのは明らかである。</p>
<figure style='margin:0 auto;text-align:center;'>
<div class="mermaid">
graph LR
Alice["Alice's Public Key"]
Bob["Bob's Public Key"]
Chris["Chris's Public Key"]
Alice-- Digital Sign -->Bob
Alice-. trust .->Bob
Bob-- Digital Sign -->Alice
Bob-- Digital Sign -->Chris
Chris-- Digital Sign -->Bob
</div></figure>
<p>Alice は Chris の公開鍵に信用できる Bob の公開鍵による電子署名を見つけたため, Bob の公開鍵と同じく Chris の公開鍵も有効であると見なすことができる。</p>
<figure style='margin:0 auto;text-align:center;'>
<div class="mermaid">
graph LR
Alice["Alice's Public Key"]
Bob["Bob's Public Key"]
Chris["Chris's Public Key"]
Alice-- Digital Sign -->Bob
Alice-. validate! .->Chris
Alice-. trust .->Bob
Bob-- Digital Sign -->Alice
Bob-- Digital Sign -->Chris
Chris-- Digital Sign -->Bob
</div></figure>
<p>これが <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の代表的な信用モデル “web of trust” の基本的な考え方である<sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup>。
このことから <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の鍵管理ににおいて「信用できる鍵」の条件は</p>
<ul>
<li>多くの電子署名(とできれば信用)が集まっていること</li>
</ul>
<p>だと分かる。
更にこのことから派生的に</p>
<ul>
<li>同じ鍵が永続的に使われ続けていること</li>
</ul>
<p>も「信用できる鍵」の条件となる。
何故なら,鍵が頻繁に変わるとその度に電子署名をやり直すことになり,鍵に署名(=信用)が集まりにくくなるからである。</p>
<h2><a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の鍵管理</h2>
<p>以上を踏まえて <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 鍵の管理について考えてみよう。</p>
<h3>ひとつの鍵で運用する場合</h3>
<p>一番簡単なケースで,ひとつの <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 鍵で全てをまかなう場合を考える。
たとえば,ふだん暗号化ツールなんて全然使わないけど git commit に電子署名するためだけに <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> を使いたい,など。</p>
<p><a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の代表的な実装である <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> の最新バージョンでは,以下に示すように,鍵の作成処理が(昔と比べて)大幅に簡略化できる。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --batch --passphrase pass123 --quick-generate-key "Alice <alice@example.com>" default default 0
</span></span><span class="line"><span class="cl">gpg: 鍵02C94DC57527A786を究極的に信用するよう記録しました
</span></span><span class="line"><span class="cl">gpg: 失効証明書を 'C:/Users/alice/AppData/Roaming/gnupg/openpgp-revocs.d\9416E477EBA825CD1694573102C94DC57527A786.rev' に保管しました。
</span></span></code></pre></div><ul>
<li><code>--batch</code> オプション<sup id="fnref:3"><a href="#fn:3" class="footnote-ref" role="doc-noteref">3</a></sup>(または <code>--pinentry-mode</code> オプションに <code>loopback</code> を指定)と <code>--passphrase</code> オプションを組み合わせて Pinentry によるパスフレーズ入力を回避できる</li>
<li><code>--quick-generate-key</code> コマンドの第1引数にユーザID,第2引数にアルゴリズム,第3引数に使用目的,第4引数に有効期限を指定する
<ul>
<li>アルゴリズムに <code>default</code> を指定するか指定しない場合は既定のアルゴリズム(RSA/2048ビット)で鍵を作成する</li>
<li>使用目的には主鍵<sup id="fnref:4"><a href="#fn:4" class="footnote-ref" role="doc-noteref">4</a></sup> の種類を指定する。通常は <code>default</code> のまま(署名と証明)でよい(指定しなければ <code>default</code>)</li>
<li>有効期限には期間(1週間なら <code>7d</code> または <code>1w</code>,1年なら <code>12m</code> または <code>1y</code> など)を指定する。 <code>0</code> を指定すると無期限になる(指定しないと有効期限が当日になる)</li>
</ul>
</li>
</ul>
<p>生成された鍵の状態は以下の通り。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --list-keys alice
</span></span><span class="line"><span class="cl">pub rsa2048 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> 9416E477EBA825CD1694573102C94DC57527A786
</span></span><span class="line"><span class="cl">uid [ 究極 ] Alice <alice@example.com>
</span></span><span class="line"><span class="cl">sub rsa2048 2017-11-23 [E]
</span></span></code></pre></div><p>作成した鍵の公開鍵を配布するには</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --export -a alice > alice-key.asc
</span></span></code></pre></div><p>として <code>alice-key.asc</code> を直接配布するか</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --keyserver keys.gnupg.net --send-key alice
</span></span></code></pre></div><p>として鍵サーバ(ここでは <a href="http://keys.gnupg.net/"><code>keys.gnupg.net</code></a>)にアップロードすればいい。</p>
<p>注意する点としてはパスフレーズと失効証明書を紛失・漏洩しないよう管理することであろう。
できれば失効証明書は普段使う PC や携帯端末とは別に管理しておくのが望ましい。
ちなみに <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> ではパスフレーズは何処にも保存されないので,パスフレーズを忘れてしまうと全くリカバリできなくなる(だからといってパスフレーズを設定しないというのは通常運用ではあり得ないが)。</p>
<p>ノートPCや携帯端末には常に紛失・盗難のリスクが付きまとうが,予防に注力しすぎて現実的でない対策を執るよりも,これはもう「起こり得ること」として「事後」がスムーズに行われるようバックアップ等の準備しておくほうが賢明である。</p>
<h3>ひとつの鍵に複数のユーザIDを付与する場合</h3>
<p>ユーザIDというのは鍵の名前 “<code>Alice <alice@examle.com></code>” の部分である。</p>
<p>たとえば,以下の鍵があったとき</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --list-keys alice
</span></span><span class="line"><span class="cl">pub rsa2048 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> B686F36CA9FDC10057EFC5D58D7E04B8CE947112
</span></span><span class="line"><span class="cl">uid [ 究極 ] Alice <alice@example.com>
</span></span><span class="line"><span class="cl">sub rsa2048 2017-11-23 [E]
</span></span></code></pre></div><p>これに新しいユーザID “<code>Alice <alice@examle2.com></code>” を付加するには <code>--quick-add-uid</code> コマンドを使って</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --quick-add-uid alice "Alice <alice@examle2.com>"
</span></span><span class="line"><span class="cl">$ gpg --update-trustdb
</span></span></code></pre></div><p>とする<sup id="fnref:5"><a href="#fn:5" class="footnote-ref" role="doc-noteref">5</a></sup>。
これで新しいユーザIDが付加された。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --list-keys alice
</span></span><span class="line"><span class="cl">pub rsa2048 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> B686F36CA9FDC10057EFC5D58D7E04B8CE947112
</span></span><span class="line"><span class="cl">uid [ 究極 ] Alice <alice@examle2.com>
</span></span><span class="line"><span class="cl">uid [ 究極 ] Alice <alice@example.com>
</span></span><span class="line"><span class="cl">sub rsa2048 2017-11-23 [E]
</span></span></code></pre></div><p>ちなみに,この鍵を <a href="http://www.mew.org/~kazu/proj/pgpdump/" title="pgpdump">pgpdump</a> にかけると以下のようになる。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --export -a alice | pgpdump -u
</span></span><span class="line"><span class="cl">Old: Public Key Packet(tag 6)(269 bytes)
</span></span><span class="line"><span class="cl"> Ver 4 - new
</span></span><span class="line"><span class="cl"> Public key creation time - Thu Nov 23 06:22:56 UTC 2017
</span></span><span class="line"><span class="cl"> Pub alg - RSA Encrypt or Sign(pub 1)
</span></span><span class="line"><span class="cl"> RSA n(2048 bits) - ...
</span></span><span class="line"><span class="cl"> RSA e(17 bits) - ...
</span></span><span class="line"><span class="cl">Old: User ID Packet(tag 13)(25 bytes)
</span></span><span class="line"><span class="cl"> User ID - Alice <alice@example.com>
</span></span><span class="line"><span class="cl">Old: Signature Packet(tag 2)(334 bytes)
</span></span><span class="line"><span class="cl"> Ver 4 - new
</span></span><span class="line"><span class="cl"> Sig type - Positive certification of a User ID and Public Key packet(0x13).
</span></span><span class="line"><span class="cl"> Pub alg - RSA Encrypt or Sign(pub 1)
</span></span><span class="line"><span class="cl"> Hash alg - SHA256(hash 8)
</span></span><span class="line"><span class="cl"> Hashed Sub: issuer fingerprint(sub 33)(21 bytes)
</span></span><span class="line"><span class="cl"> v4 - Fingerprint - b6 86 f3 6c a9 fd c1 00 57 ef c5 d5 8d 7e 04 b8 ce 94 71 12
</span></span><span class="line"><span class="cl"> Hashed Sub: signature creation time(sub 2)(4 bytes)
</span></span><span class="line"><span class="cl"> Time - Thu Nov 23 06:22:56 UTC 2017
</span></span><span class="line"><span class="cl"> Hashed Sub: key flags(sub 27)(1 bytes)
</span></span><span class="line"><span class="cl"> Flag - This key may be used to certify other keys
</span></span><span class="line"><span class="cl"> Flag - This key may be used to sign data
</span></span><span class="line"><span class="cl"> Hashed Sub: preferred symmetric algorithms(sub 11)(4 bytes)
</span></span><span class="line"><span class="cl"> Sym alg - AES with 256-bit key(sym 9)
</span></span><span class="line"><span class="cl"> Sym alg - AES with 192-bit key(sym 8)
</span></span><span class="line"><span class="cl"> Sym alg - AES with 128-bit key(sym 7)
</span></span><span class="line"><span class="cl"> Sym alg - Triple-DES(sym 2)
</span></span><span class="line"><span class="cl"> Hashed Sub: preferred hash algorithms(sub 21)(5 bytes)
</span></span><span class="line"><span class="cl"> Hash alg - SHA256(hash 8)
</span></span><span class="line"><span class="cl"> Hash alg - SHA384(hash 9)
</span></span><span class="line"><span class="cl"> Hash alg - SHA512(hash 10)
</span></span><span class="line"><span class="cl"> Hash alg - SHA224(hash 11)
</span></span><span class="line"><span class="cl"> Hash alg - SHA1(hash 2)
</span></span><span class="line"><span class="cl"> Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
</span></span><span class="line"><span class="cl"> Comp alg - ZLIB <RFC1950>(comp 2)
</span></span><span class="line"><span class="cl"> Comp alg - BZip2(comp 3)
</span></span><span class="line"><span class="cl"> Comp alg - ZIP <RFC1951>(comp 1)
</span></span><span class="line"><span class="cl"> Hashed Sub: features(sub 30)(1 bytes)
</span></span><span class="line"><span class="cl"> Flag - Modification detection (packets 18 and 19)
</span></span><span class="line"><span class="cl"> Hashed Sub: key server preferences(sub 23)(1 bytes)
</span></span><span class="line"><span class="cl"> Flag - No-modify
</span></span><span class="line"><span class="cl"> Sub: issuer key ID(sub 16)(8 bytes)
</span></span><span class="line"><span class="cl"> Key ID - 0x8D7E04B8CE947112
</span></span><span class="line"><span class="cl"> Hash left 2 bytes - 05 21
</span></span><span class="line"><span class="cl"> RSA m^d mod n(2047 bits) - ...
</span></span><span class="line"><span class="cl"> -> PKCS-1
</span></span><span class="line"><span class="cl">Old: User ID Packet(tag 13)(25 bytes)
</span></span><span class="line"><span class="cl"> User ID - Alice <alice@examle2.com>
</span></span><span class="line"><span class="cl">Old: Signature Packet(tag 2)(334 bytes)
</span></span><span class="line"><span class="cl"> Ver 4 - new
</span></span><span class="line"><span class="cl"> Sig type - Positive certification of a User ID and Public Key packet(0x13).
</span></span><span class="line"><span class="cl"> Pub alg - RSA Encrypt or Sign(pub 1)
</span></span><span class="line"><span class="cl"> Hash alg - SHA256(hash 8)
</span></span><span class="line"><span class="cl"> Hashed Sub: issuer fingerprint(sub 33)(21 bytes)
</span></span><span class="line"><span class="cl"> v4 - Fingerprint - b6 86 f3 6c a9 fd c1 00 57 ef c5 d5 8d 7e 04 b8 ce 94 71 12
</span></span><span class="line"><span class="cl"> Hashed Sub: signature creation time(sub 2)(4 bytes)
</span></span><span class="line"><span class="cl"> Time - Thu Nov 23 06:33:28 UTC 2017
</span></span><span class="line"><span class="cl"> Hashed Sub: key flags(sub 27)(1 bytes)
</span></span><span class="line"><span class="cl"> Flag - This key may be used to certify other keys
</span></span><span class="line"><span class="cl"> Flag - This key may be used to sign data
</span></span><span class="line"><span class="cl"> Hashed Sub: preferred symmetric algorithms(sub 11)(4 bytes)
</span></span><span class="line"><span class="cl"> Sym alg - AES with 256-bit key(sym 9)
</span></span><span class="line"><span class="cl"> Sym alg - AES with 192-bit key(sym 8)
</span></span><span class="line"><span class="cl"> Sym alg - AES with 128-bit key(sym 7)
</span></span><span class="line"><span class="cl"> Sym alg - Triple-DES(sym 2)
</span></span><span class="line"><span class="cl"> Hashed Sub: preferred hash algorithms(sub 21)(5 bytes)
</span></span><span class="line"><span class="cl"> Hash alg - SHA256(hash 8)
</span></span><span class="line"><span class="cl"> Hash alg - SHA384(hash 9)
</span></span><span class="line"><span class="cl"> Hash alg - SHA512(hash 10)
</span></span><span class="line"><span class="cl"> Hash alg - SHA224(hash 11)
</span></span><span class="line"><span class="cl"> Hash alg - SHA1(hash 2)
</span></span><span class="line"><span class="cl"> Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
</span></span><span class="line"><span class="cl"> Comp alg - ZLIB <RFC1950>(comp 2)
</span></span><span class="line"><span class="cl"> Comp alg - BZip2(comp 3)
</span></span><span class="line"><span class="cl"> Comp alg - ZIP <RFC1951>(comp 1)
</span></span><span class="line"><span class="cl"> Hashed Sub: features(sub 30)(1 bytes)
</span></span><span class="line"><span class="cl"> Flag - Modification detection (packets 18 and 19)
</span></span><span class="line"><span class="cl"> Hashed Sub: key server preferences(sub 23)(1 bytes)
</span></span><span class="line"><span class="cl"> Flag - No-modify
</span></span><span class="line"><span class="cl"> Sub: issuer key ID(sub 16)(8 bytes)
</span></span><span class="line"><span class="cl"> Key ID - 0x8D7E04B8CE947112
</span></span><span class="line"><span class="cl"> Hash left 2 bytes - 7d 5a
</span></span><span class="line"><span class="cl"> RSA m^d mod n(2048 bits) - ...
</span></span><span class="line"><span class="cl"> -> PKCS-1
</span></span><span class="line"><span class="cl">Old: Public Subkey Packet(tag 14)(269 bytes)
</span></span><span class="line"><span class="cl"> Ver 4 - new
</span></span><span class="line"><span class="cl"> Public key creation time - Thu Nov 23 06:22:56 UTC 2017
</span></span><span class="line"><span class="cl"> Pub alg - RSA Encrypt or Sign(pub 1)
</span></span><span class="line"><span class="cl"> RSA n(2048 bits) - ...
</span></span><span class="line"><span class="cl"> RSA e(17 bits) - ...
</span></span><span class="line"><span class="cl">Old: Signature Packet(tag 2)(310 bytes)
</span></span><span class="line"><span class="cl"> Ver 4 - new
</span></span><span class="line"><span class="cl"> Sig type - Subkey Binding Signature(0x18).
</span></span><span class="line"><span class="cl"> Pub alg - RSA Encrypt or Sign(pub 1)
</span></span><span class="line"><span class="cl"> Hash alg - SHA256(hash 8)
</span></span><span class="line"><span class="cl"> Hashed Sub: issuer fingerprint(sub 33)(21 bytes)
</span></span><span class="line"><span class="cl"> v4 - Fingerprint - b6 86 f3 6c a9 fd c1 00 57 ef c5 d5 8d 7e 04 b8 ce 94 71 12
</span></span><span class="line"><span class="cl"> Hashed Sub: signature creation time(sub 2)(4 bytes)
</span></span><span class="line"><span class="cl"> Time - Thu Nov 23 06:22:56 UTC 2017
</span></span><span class="line"><span class="cl"> Hashed Sub: key flags(sub 27)(1 bytes)
</span></span><span class="line"><span class="cl"> Flag - This key may be used to encrypt communications
</span></span><span class="line"><span class="cl"> Flag - This key may be used to encrypt storage
</span></span><span class="line"><span class="cl"> Sub: issuer key ID(sub 16)(8 bytes)
</span></span><span class="line"><span class="cl"> Key ID - 0x8D7E04B8CE947112
</span></span><span class="line"><span class="cl"> Hash left 2 bytes - 3a a7
</span></span><span class="line"><span class="cl"> RSA m^d mod n(2047 bits) - ...
</span></span><span class="line"><span class="cl"> -> PKCS-1
</span></span></code></pre></div><p>ユーザID毎に電子署名(自己署名)が付与されているのがお分かりだろうか。</p>
<p>ひとつの鍵に複数のユーザIDを付与することに関しては昔から賛否あるのだが,手段が提供されていることは覚えておいて損はないだろう。</p>
<h3>用途によって鍵を使い分けたい場合</h3>
<p>たとえば,暗号化メール,リリースファイルの電子署名, git commit 時の電子署名といった用途毎に異なる鍵を使いたいことがある。
その場合でもそれぞれ鍵を生成して運用すればいいのだが,新しい鍵を作る度にそれぞれの鍵とやり取りを行うユーザが毎度電子署名を行うのは相当に煩雑な作業である。</p>
<p>そこで「ルート鍵」と「運用鍵」の2種類の鍵を作って運用する。
具体的にはルート鍵と各運用鍵との間で電子署名を交わす。</p>
<figure style='margin:0 auto;text-align:center;'>
<div class="mermaid">
graph LR
rt[Root Key]-- Digital Sign -->op1[Operation Key 1]
op1-- Digital Sign -->rt
rt-- Digital Sign -->op2[Operation Key 2]
op2-- Digital Sign -->rt
</div></figure>
<p>運用鍵とやり取りするユーザは,各運用鍵ではなく,ルート鍵と署名を交わし信用度を設定することによって各運用鍵の有効性を確認できる。</p>
<figure style='margin:0 auto;text-align:center;'>
<div class="mermaid">
graph LR
usr[User's Key]
rt[Root Key]
op1[Operation Key 1]
op2[Operation Key 2]
usr-- Digital Sign -->rt
usr-. trust .->rt
rt-- Digital Sign -->usr
usr-. validate .->op1
rt-- Digital Sign -->op1
rt-- Digital Sign -->op2
usr-. validate .->op2
</div></figure>
<p>この方法ならユーザも各運用鍵もルート鍵とのみ信用関係を構築すればいいので柔軟な運用が可能になる。
欠点としてはルート鍵の管理が煩雑になりがちで信用に関する責務も重くなるため,かなり慎重な運用が求められることであろう。</p>
<h4>Alice のルート鍵と運用鍵</h4>
<p>では実際にやってみよう。</p>
<p>まず Alice がルート鍵と運用鍵の運用を行うとする。
ルート鍵は電子署名を行うだけの鍵なので,以下のように署名専用鍵として作成する(アルゴリズムは DSA/3072ビット にしてみた)。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --batch --passphrase pass123 --quick-generate-key "Alice (root) <alice@example.com>" dsa3072 default 0
</span></span><span class="line"><span class="cl">gpg: *警告*: いくつかのOpenPGPプログラムはこのダイジェスト長のDSA鍵を扱うことができません
</span></span><span class="line"><span class="cl">gpg: 鍵B965D53DB907EF0Eを究極的に信用するよう記録しました
</span></span><span class="line"><span class="cl">gpg: 失効証明書を 'C:/Users/spiegel/AppData/Roaming/gnupg/openpgp-revocs.d\3F8EFC477F9D4D49AA6C308FB965D53DB907EF0E.rev' に保管しました。
</span></span></code></pre></div><p>もうひとつ。
運用鍵も作っておく。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --batch --passphrase pass123 --quick-generate-key "Alice (commit) <alice@example.com>" default default 0
</span></span><span class="line"><span class="cl">gpg: 鍵DFFC3F67BBB3C083を究極的に信用するよう記録しました
</span></span><span class="line"><span class="cl">gpg: 失効証明書を 'C:/Users/spiegel/AppData/Roaming/gnupg/openpgp-revocs.d\A3CEFEEEDA222024F325C403DFFC3F67BBB3C083.rev' に保管しました。
</span></span></code></pre></div><p>この2つの鍵でお互いに電子署名を交わす(パスフレースの入力あり)。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg -u 3F8EFC477F9D4D49AA6C308FB965D53DB907EF0E --quick-sign-key A3CEFEEEDA222024F325C403DFFC3F67BBB3C083
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">sec rsa2048/DFFC3F67BBB3C083
</span></span><span class="line"><span class="cl"> 作成: 2017-11-23 有効期限: 無期限 利用法: SC
</span></span><span class="line"><span class="cl"> 信用: 究極 有効性: 究極
</span></span><span class="line"><span class="cl"> 主鍵フィンガープリント: A3CE FEEE DA22 2024 F325 C403 DFFC 3F67 BBB3 C083
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"> Alice (commit) <alice@example.com>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">$ gpg -u A3CEFEEEDA222024F325C403DFFC3F67BBB3C083 --quick-sign-key 3F8EFC477F9D4D49AA6C308FB965D53DB907EF0E
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">sec dsa3072/B965D53DB907EF0E
</span></span><span class="line"><span class="cl"> 作成: 2017-11-23 有効期限: 無期限 利用法: SC
</span></span><span class="line"><span class="cl"> 信用: 究極 有効性: 究極
</span></span><span class="line"><span class="cl"> 主鍵フィンガープリント: 3F8E FC47 7F9D 4D49 AA6C 308F B965 D53D B907 EF0E
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"> Alice (root) <alice@example.com>
</span></span></code></pre></div><p>これで Alice の2つの鍵の署名状態はこんな感じになった。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --list-sigs alice
</span></span><span class="line"><span class="cl">pub dsa3072 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> 3F8EFC477F9D4D49AA6C308FB965D53DB907EF0E
</span></span><span class="line"><span class="cl">uid [ 究極 ] Alice (root) <alice@example.com>
</span></span><span class="line"><span class="cl">sig 3 B965D53DB907EF0E 2017-11-23 Alice (root) <alice@example.com>
</span></span><span class="line"><span class="cl">sig DFFC3F67BBB3C083 2017-11-23 Alice (commit) <alice@example.com>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">pub rsa2048 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> A3CEFEEEDA222024F325C403DFFC3F67BBB3C083
</span></span><span class="line"><span class="cl">uid [ 究極 ] Alice (commit) <alice@example.com>
</span></span><span class="line"><span class="cl">sig 3 DFFC3F67BBB3C083 2017-11-23 Alice (commit) <alice@example.com>
</span></span><span class="line"><span class="cl">sig B965D53DB907EF0E 2017-11-23 Alice (root) <alice@example.com>
</span></span><span class="line"><span class="cl">sub rsa2048 2017-11-23 [E]
</span></span><span class="line"><span class="cl">sig DFFC3F67BBB3C083 2017-11-23 Alice (commit) <alice@example.com>
</span></span></code></pre></div><p>一方の主鍵に他方の鍵の電子署名が付与されているのが分かるだろうか。</p>
<h4>Bob 鍵で Alice のルート鍵に電子署名する</h4>
<p>今度は Bob の側である。
まずは Bob の公開鍵をこんな感じで作ってみた(作成操作は省略)。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --list-keys bob
</span></span><span class="line"><span class="cl">pub rsa2048 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> B4E708652A1E81445B328A3D93F496726CBE8335
</span></span><span class="line"><span class="cl">uid [ 究極 ] Bob <bob@example.com>
</span></span><span class="line"><span class="cl">sub rsa2048 2017-11-23 [E]
</span></span></code></pre></div><p>この環境に先程の Alice の公開鍵をインポートしてみる。
まずはルート鍵から。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --import alice-root.asc
</span></span><span class="line"><span class="cl">gpg: key B965D53DB907EF0E: 鍵がないため1個の署名は検査しません
</span></span><span class="line"><span class="cl">gpg: 鍵B965D53DB907EF0E: 公開鍵"Alice (root) <alice@example.com>"をインポートしました
</span></span><span class="line"><span class="cl">gpg: 処理数の合計: 1
</span></span><span class="line"><span class="cl">gpg: インポート: 1
</span></span><span class="line"><span class="cl">gpg: marginals needed: 3 completes needed: 1 trust model: pgp
</span></span><span class="line"><span class="cl">gpg: 深さ: 0 有効性: 1 署名: 0 信用: 0-, 0q, 0n, 0m, 0f, 1u
</span></span></code></pre></div><p>当然ながら,この時点では読み込んだルート鍵の有効性は不明である。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --list-keys alice
</span></span><span class="line"><span class="cl">pub dsa3072 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> 3F8EFC477F9D4D49AA6C308FB965D53DB907EF0E
</span></span><span class="line"><span class="cl">uid [ 不明 ] Alice (root) <alice@example.com>
</span></span></code></pre></div><p>では,ルート鍵に Bob の鍵で署名しよう<sup id="fnref:6"><a href="#fn:6" class="footnote-ref" role="doc-noteref">6</a></sup>(パスフレースの入力あり)。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --quick-sign-key 3F8EFC477F9D4D49AA6C308FB965D53DB907EF0E
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">pub dsa3072/B965D53DB907EF0E
</span></span><span class="line"><span class="cl"> 作成: 2017-11-23 有効期限: 無期限 利用法: SC
</span></span><span class="line"><span class="cl"> 信用: 不明の 有効性: 不明の
</span></span><span class="line"><span class="cl"> 主鍵フィンガープリント: 3F8E FC47 7F9D 4D49 AA6C 308F B965 D53D B907 EF0E
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"> Alice (root) <alice@example.com>
</span></span></code></pre></div><p>これでルート鍵の有効性は「充分」になった。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --list-keys alice
</span></span><span class="line"><span class="cl">pub dsa3072 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> 3F8EFC477F9D4D49AA6C308FB965D53DB907EF0E
</span></span><span class="line"><span class="cl">uid [ 充分 ] Alice (root) <alice@example.com>
</span></span></code></pre></div><p>さらに信用データベースを更新して信用度も設定する。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --update-trustdb
</span></span><span class="line"><span class="cl">gpg: marginals needed: 3 completes needed: 1 trust model: pgp
</span></span><span class="line"><span class="cl">gpg: 深さ: 0 有効性: 1 署名: 1 信用: 0-, 0q, 0n, 0m, 0f, 1u
</span></span><span class="line"><span class="cl">信用度が指定されていません:
</span></span><span class="line"><span class="cl">pub dsa3072 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> "Alice (root) <alice@example.com>"
</span></span><span class="line"><span class="cl"> 主鍵フィンガープリント: 3F8E FC47 7F9D 4D49 AA6C 308F B965 D53D B907 EF0E
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">他のユーザの鍵を正しく検証するために、このユーザの信用度を決めてください
</span></span><span class="line"><span class="cl">(パスポートを見せてもらったり、他から得たフィンガープリントを検査したり、などなど)
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"> 1 = 知らない、または何とも言えない
</span></span><span class="line"><span class="cl"> 2 = 信用し ない
</span></span><span class="line"><span class="cl"> 3 = まぁまぁ信用する
</span></span><span class="line"><span class="cl"> 4 = 充分に信用する
</span></span><span class="line"><span class="cl"> s = この鍵はとばす
</span></span><span class="line"><span class="cl"> q = 終了
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">あなたの決定は? 4
</span></span><span class="line"><span class="cl">gpg: 深さ: 1 有効性: 1 署名: 0 信用: 0-, 0q, 0n, 0m, 1f, 0u
</span></span><span class="line"><span class="cl"> 3F8EFC477F9D4D49AA6C308FB965D53DB907EF0E
</span></span></code></pre></div><p>ここでは「充分に信用する」を選択した。</p>
<p>次に運用鍵もインポートする(操作は同じなので省略)。
この時点で Alice の公開鍵の状態を見ると</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --list-keys alice
</span></span><span class="line"><span class="cl">pub dsa3072 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> 3F8EFC477F9D4D49AA6C308FB965D53DB907EF0E
</span></span><span class="line"><span class="cl">uid [ 充分 ] Alice (root) <alice@example.com>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">pub rsa2048 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> A3CEFEEEDA222024F325C403DFFC3F67BBB3C083
</span></span><span class="line"><span class="cl">uid [ 充分 ] Alice (commit) <alice@example.com>
</span></span><span class="line"><span class="cl">sub rsa2048 2017-11-23 [E]
</span></span></code></pre></div><p>運用鍵の有効性も既に「充分」になっていることが分かると思う。
ちなみにルート鍵の信用度を「まぁまぁ信用する」にすると</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --list-keys alice
</span></span><span class="line"><span class="cl">pub dsa3072 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> 3F8EFC477F9D4D49AA6C308FB965D53DB907EF0E
</span></span><span class="line"><span class="cl">uid [ 充分 ] Alice (root) <alice@example.com>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">pub rsa2048 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> A3CEFEEEDA222024F325C403DFFC3F67BBB3C083
</span></span><span class="line"><span class="cl">uid [まぁまぁ] Alice (commit) <alice@example.com>
</span></span><span class="line"><span class="cl">sub rsa2048 2017-11-23 [E]
</span></span></code></pre></div><p>運用鍵の有効性が「まぁまぁ」になる。</p>
<p>独りでこうした運用をやるメリットは殆どないが,プロジェクト・チーム等で一括して鍵管理を行いたい場合は有効な手段だと思う。</p>
<h2>有効期限について</h2>
<p>この記事ではすべての鍵を「無期限」で設定している。
公開鍵の有効期限をどのようにするかは意見が別れるところだと思うが,私個人としては原則として「無期限」にすることをお薦めする。
何故なら <a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 鍵は永続性と一貫性が重要だからである。</p>
<p>公開鍵に有効期限を設ける理由としては</p>
<ul>
<li>期間の決まったプロジェクト内でのみ使用する鍵である</li>
<li>チーム・メンバの出入りが激しく無期限では却って管理が煩雑になる</li>
<li>鍵のセキュリティ強度の問題から期限を切って運用したい(たとえば RSA/2048ビット鍵が acceptable なのは2030年までである)</li>
</ul>
<p>といったところだろうか。
これならば,これまで述べたようにルート鍵と運用鍵を分けて,ルート鍵の方で永続性と一貫性を担保するように運用していくのがよいだろう。</p>
<p>自分の鍵であれば有効期限はいつでも変更できる(変更時にパスフレーズ入力あり)。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --list-keys A3CEFEEEDA222024F325C403DFFC3F67BBB3C083
</span></span><span class="line"><span class="cl">pub rsa2048 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> A3CEFEEEDA222024F325C403DFFC3F67BBB3C083
</span></span><span class="line"><span class="cl">uid [ 究極 ] Alice (commit) <alice@example.com>
</span></span><span class="line"><span class="cl">sub rsa2048 2017-11-23 [E]
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">$ gpg --quick-set-expire A3CEFEEEDA222024F325C403DFFC3F67BBB3C083 2y
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">$ gpg --list-keys A3CEFEEEDA222024F325C403DFFC3F67BBB3C083
</span></span><span class="line"><span class="cl">pub rsa2048 2017-11-23 [SC] [有効期限: 2019-11-23]
</span></span><span class="line"><span class="cl"> A3CEFEEEDA222024F325C403DFFC3F67BBB3C083
</span></span><span class="line"><span class="cl">uid [ 究極 ] Alice (commit) <alice@example.com>
</span></span><span class="line"><span class="cl">sub rsa2048 2017-11-23 [E] [有効期限: 2019-11-23]
</span></span></code></pre></div><p>しかし,有効期限を随時延長していく運用は鍵のオーナーもそれを使うユーザも手間が増えるだけであまりメリットがない<sup id="fnref:7"><a href="#fn:7" class="footnote-ref" role="doc-noteref">7</a></sup>。
<a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> 鍵は(今のところ)利用するユーザに公開鍵の変更を自動的に通知・配信する仕組みがないので(それとも cron で鍵サーバへアクセスする?),ユーザ側の手間の多い運用では取りこぼしが出る可能性が大きくなる。</p>
<h2>鍵を失効させる</h2>
<p>秘密鍵が漏洩するなどして鍵の失効が必要になった場合には,鍵作成時に作られた失効証明書を使って失効させる<sup id="fnref:8"><a href="#fn:8" class="footnote-ref" role="doc-noteref">8</a></sup>。
鍵作成時に作られた失効証明書の中身はこんな感じになっている。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ cd C:/Users/alice/AppData/Roaming/gnupg/openpgp-revocs.d
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">$ cat 9416E477EBA825CD1694573102C94DC57527A786.rev
</span></span><span class="line"><span class="cl">これは失効証明書でこちらのOpenPGP鍵に対するものです:
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">pub rsa2048 2017-11-23 [SC]
</span></span><span class="line"><span class="cl"> 9416E477EBA825CD1694573102C94DC57527A786
</span></span><span class="line"><span class="cl">uid Alice <alice@example.com>
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">失効証明書は "殺すスイッチ" のようなもので、鍵がそれ以上使えない
</span></span><span class="line"><span class="cl">ように公に宣言するものです。一度発行されると、そのような失効証明書は
</span></span><span class="line"><span class="cl">撤回することはできません。
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">秘密鍵のコンプロマイズや紛失の場合、これを使ってこの鍵を失効させます。
</span></span><span class="line"><span class="cl">しかし、秘密鍵がまだアクセス可能である場合、新しい失効証明書を生成し、
</span></span><span class="line"><span class="cl">失効の理由をつける方がよいでしょう。詳細は、GnuPGマニュアルのgpgコマン
</span></span><span class="line"><span class="cl">ド "--generate-revocation"の記述をご覧ください。
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">このファイルを誤って使うのを避けるため、以下ではコロンが5つのダッシュ
</span></span><span class="line"><span class="cl">の前に挿入されます。この失効証明書をインポートして公開する前に、テク
</span></span><span class="line"><span class="cl">スト・エディタでこのコロンを削除してください。
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">:-----BEGIN PGP PUBLIC KEY BLOCK-----
</span></span><span class="line"><span class="cl">Comment: This is a revocation certificate
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">iQE2BCABCAAgFiEElBbkd+uoJc0WlFcxAslNxXUnp4YFAloWYkcCHQAACgkQAslN
</span></span><span class="line"><span class="cl">xXUnp4aG1wf/XoyxQPks2JlJ93ghQALdqCIxFPh015q21K53u0rVwTsMocwdGowR
</span></span><span class="line"><span class="cl">l+/UppyBxnGyU1uIba68D787INlruMzsOyUTuruCUZ5XJpiuYYVXcRuovUmCREWF
</span></span><span class="line"><span class="cl">EbW1DGd1lzmrO8cr70qu3yVCMYjGOQ6NA0fh1lpKTpFqHc3GC+ue19RDoVY1KnCC
</span></span><span class="line"><span class="cl">YsWuNom4PAuUyHlH3uJLM9+F9J2Qec+0PIedxHyxuIStWOSg+/TGjD4cP3FEItIt
</span></span><span class="line"><span class="cl">giRxx6qLWcK+bfg6WXv7I3+FA2J8eRKjLoD/vsZX+FpxG7T+c4mvfTUgxn0+bZD9
</span></span><span class="line"><span class="cl">gxTKlFWg2bhKTcxi0EsJ9XAEmocvOolwPQ==
</span></span><span class="line"><span class="cl">=ShPY
</span></span><span class="line"><span class="cl">-----END PGP PUBLIC KEY BLOCK-----
</span></span></code></pre></div><p>実際に使う場合は</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">:-----BEGIN PGP PUBLIC KEY BLOCK-----
</span></span></code></pre></div><p>の先頭のコロンを削除して使う。
失効処理を行うには <code>--import</code> コマンドで失効証明書をインポートすればよい。</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --import 9416E477EBA825CD1694573102C94DC57527A786.rev
</span></span><span class="line"><span class="cl">gpg: 鍵02C94DC57527A786:"Alice <alice@example.com>"失効証明書をインポートしました
</span></span><span class="line"><span class="cl">gpg: 処理数の合計: 1
</span></span><span class="line"><span class="cl">gpg: 新しい鍵の失効: 1
</span></span><span class="line"><span class="cl">gpg: marginals needed: 3 completes needed: 1 trust model: pgp
</span></span><span class="line"><span class="cl">gpg: 深さ: 0 有効性: 1 署名: 0 信用: 0-, 0q, 0n, 0m, 0f, 1u
</span></span></code></pre></div><p>これで鍵の状態は</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --list-keys alice
</span></span><span class="line"><span class="cl">pub rsa2048 2017-11-23 [SC] [失効: 2017-11-23]
</span></span><span class="line"><span class="cl"> 9416E477EBA825CD1694573102C94DC57527A786
</span></span><span class="line"><span class="cl">uid [ 失効 ] Alice <alice@example.com>
</span></span></code></pre></div><p>となり失効したことが分かる。
<strong>失効した公開鍵を配布するのを忘れずに!</strong></p>
<h2>ブックマーク</h2>
<ul>
<li>
<p><a href="https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Key-Management.html">Using the GNU Privacy Guard: OpenPGP Key Management</a></p>
</li>
<li>
<p><a href="https://baldanders.info/spiegel/cc-license/">わかる! OpenPGP 暗号</a></p>
</li>
<li>
<p><a href="https://text.baldanders.info/remark/2016/03/using-gnupg-modern-version-1/">GnuPG for Windows ― インストール編</a></p>
</li>
<li>
<p><a href="https://text.baldanders.info/remark/2016/03/using-gnupg-modern-version-2/">GnuPG for Windows ― gpg-agent について</a></p>
</li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t6yHHVwEL._SL160_.jpg" width="113" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号技術入門 第3版 秘密の国のアリス</a></dt>
<dd>結城 浩 (著)</dd>
<dd>SBクリエイティブ 2015-08-25 (Release 2015-09-17)</dd>
<dd>Kindle版</dd>
<dd>B015643CPE (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-09-20">2015-09-20</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号技術入門 第3版 -->
<div class="footnotes" role="doc-endnotes">
<hr>
<ol>
<li id="fn:1">
<p>相手の公開鍵に電子署名するには (1) 相手の公開鍵を貰って <code>--import</code> (または鍵サーバから <code>--recv-keys</code>)する (2) インポートした鍵に <code>--sign-key</code> する (3) 署名した公開鍵を <code>--export</code> して相手に返す(または鍵サーバへ <code>--send-keys</code>) といった手順を踏む。これをひとりひとりやるのは割と面倒なので,複数人が一度に電子署名を交わすために「<a href="https://en.wikipedia.org/wiki/Key_signing_party" title="Key signing party - Wikipedia">キーサイン・パーティ(key signing party)</a>」が行われることがある。日本ではあまり聞かないけど。 <a href="#fnref:1" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:2">
<p>もう少し詳しく言うと,公開鍵への電子署名の際に「信用度」を設定し,集まった「信用度」の累積から公開鍵の「有効性」を機械的に判定する。なので(信用度が分からない)全く未知の人の電子署名がいくらあっても「有効性」は上がりにくい。また公開鍵に電子署名を施すことは相手の鍵をある程度以上信用していることになるため,よく分からない鍵に対して安易に電子署名を行うことは避けるべきである。なお,現行バージョンの <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> では web of trust 以外にも X.509 や <a href="https://en.wikipedia.org/wiki/Trust_on_first_use" title="Trust on first use - Wikipedia">Tofu (Trust on first use)</a> といった信用モデルもサポートしている。 <a href="#fnref:2" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:3">
<p><code>--gen-key</code> コマンドに <code>--batch</code> オプションを組み合わせて設定ファイルから鍵を作成することも可能である。詳しい方法は “<a href="https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html">Unattended GPG key generation</a>” が参考になるだろう。 <a href="#fnref:3" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:4">
<p><a href="http://tools.ietf.org/html/rfc4880" title="RFC 4880 - OpenPGP Message Format">OpenPGP</a> の鍵は1つの主鍵(primary key)と0個以上の副鍵(subkey)で構成されている。主鍵は必ず電子署名用の鍵になっていて,この主鍵にユーザID(とその自己署名)や他の鍵からの電子署名が付与される。副鍵は暗号化または電子署名用の鍵である。たとえば,データの暗号化と復号は実際にはこの副鍵を使って行う。副鍵は個別に追加したり失効したりできる。ちなみに <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> では通常のやり方では暗号化機能のみの鍵は作れない。電子署名機能のみの鍵は作ることができる。 <a href="#fnref:4" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:5">
<p><code>--update-trustdb</code> コマンドは信用データベース(trustdb)の更新コマンドである。現行バージョンの <a href="https://gnupg.org/" title="The GNU Privacy Guard">GnuPG</a> では信用度は <code>trustdb.gpg</code> ファイルを使って鍵束とは独立に管理される。通常は鍵の状態が変わると自動的に信用データベースが更新されるのだが,自動更新しない場合は <code>--update-trustdb</code> コマンドで更新できる。なお,他ユーザの公開鍵に電子署名を施した場合は <code>--update-trustdb</code> コマンドを起動して署名した鍵の信用度を設定する。信用度の設定は <code>--edit-key</code> コマンドの編集モードでも設定・変更が可能である。 <a href="#fnref:5" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:6">
<p>公開鍵に電子署名したことを公開したくない場合は <code>--lsign-key</code> コマンドで署名する。 <code>--lsign-key</code> コマンドで付与した署名はエクスポートされないため他ユーザには公開されない。公開鍵に関する確証はないけど取り敢えず使いたいという場合には有効な手だろう。 <a href="#fnref:6" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:7">
<p>公開鍵の更新を鍵オーナーの存在証明に使うのは,あまり筋のいい運用とは思えない。 <a href="#fnref:7" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
<li id="fn:8">
<p>または <code>--gen-revoke</code> コマンドで失効証明書を作成する。 <code>--gen-revoke</code> コマンドで作成した場合は失効理由も含めることができる。 <a href="#fnref:8" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
</ol>
</div>
HTTPS 通信監視機器のリスク
tag:text.Baldanders.info,2017-03-21:/remark/2017/03/security-risk-of-https-interception/
2017-03-21T11:32:28+00:00
2020-01-05T11:59:50+00:00
2015年の CERT/CC ブログ記事「The Risks of SSL Inspection」に関する注意喚起が今更ながら出ている。
Spiegel
https://baldanders.info/profile/
<p>2015年の CERT/CC ブログ記事 “<a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a>” に関する注意喚起が今更ながら出ている。</p>
<ul>
<li><a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a>
<ul>
<li><span><a href="https://jhalderm.com/pub/papers/interception-ndss17.pdf">The Security Impact of HTTPS Interception <sup><i class="far fa-file-pdf"></i></sup></a></span></li>
<li><a href="https://www.us-cert.gov/ncas/alerts/TA17-075A">HTTPS Interception Weakens TLS Security | US-CERT</a></li>
<li><a href="http://jvn.jp/ta/JVNTA96603741/">JVNTA#96603741: HTTPS 通信監視機器によるセキュリティ強度低下の問題</a></li>
</ul>
</li>
</ul>
<p>「HTTPS 通信監視機器」というのは,ぶっちゃけていうと, HTTPS 暗号通信<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> に「中間者攻撃(man-in-the-middle attack)」を仕掛けて通信を傍受し malware 等を検出・排除する「セキュリティ製品」である。</p>
<p>HTTPS 通信監視機器のいくつかにはセキュリティ上の問題が存在する。
“<a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a>” から抜き出してみよう。</p>
<ol>
<li>Incomplete validation of upstream certificate validity</li>
<li>Not conveying validation of upstream certificate to the client</li>
<li>Overloading of certificate Canonical Name (CN) field</li>
<li>Use of the application layer to convey certificate validity</li>
<li>Use of a User-Agent HTTP header to determine when to validate a certificate</li>
<li>Communication before warning</li>
<li>Same root CA certificate</li>
</ol>
<p>これらの問題があると推測される製品のリストが “<a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a>” に挙がっているので該当者は確認してみるとよいだろう。
また以下のサイトからも確認できる。</p>
<ul>
<li><a href="https://badssl.com/">badssl.com</a></li>
</ul>
<p>“<a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a>” では以下のように結論付けている。</p>
<figure lang="en">
<blockquote>
<q>SSL and TLS do not provide the level of end-to-end security that users may expect. Even in absence of SSL inspection, there are problems with how well browsers are conveying SSL information to users. The fact that "SSL inspection" is a phrase that exists, should be a blazing red flag that what you think SSL is doing for you is fundamentally broken.</q>
</blockquote>
<figcaption><div>via <q><a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a></q></div></figcaption>
</figure>
<p><a href="https://baldanders.info/blog/000812/" title="HTTPS Deep Inspection — Baldanders.info">以前も書いた</a>が,HTTPS 通信監視機器(あるいは HTTPS Deep Inspection)の存在自体がインターネットの “End to End” 原則を崩すものであり,ひいては「ネットの中立性」に楔を入れるものである。
しかし「<a href="https://text.baldanders.info/remark/2016/03/vulnerability-cross-protocol-attack-on-tls-using-sslv2/" title="SSLv2 を有効にしている TLS 実装の脆弱性 ― 馬も鹿も暗号化する時代のセキュリティ">馬も鹿も暗号化する時代</a>」にこの原則は風前の灯である。
たとえば <a href="https://text.baldanders.info/remark/2016/07/cms/" title="「自分で面倒見られる子」だけが CMS を導入しなさい">CMS の面倒すらろくすっぽ見られない</a>ユーザが「うちも <a href="https://letsencrypt.org/" title="Let's Encrypt - Free SSL/TLS Certificates">Let’s la Encrypt</a>」とか言い出して脆弱性だらけのサイトを暗号化したらどうなるのか。</p>
<p>ネットワーク・セキュリティ専門家から企業あるいは私たち個人に至るまで,場当たりな対処に満足するのではなく,この「現実」にきちんと向き合うべきだと思うのだが,どうだろう。</p>
<h2>【おまけの追記】公開鍵基盤が担保するもの</h2>
<p>他の事象だが同じ公開鍵基盤(Public Key Infrastructure; PKI)に関連している事柄なので,おまけの追記ということで。</p>
<ul>
<li><a href="http://www.computerworld.com/article/3184573/security/to-punish-symantec-google-may-distrust-a-third-of-the-webs-ssl-certificates.html">To punish Symantec, Google may distrust a third of the web’s SSL certificates | Computerworld</a></li>
<li><a href="http://notchained.hatenablog.com/entry/2017/03/27/090554">Symantecが再びGoogleの信頼を失った件についてのメモ - Technically, technophobic.</a></li>
<li><a href="https://japan.cnet.com/article/35098759/">グーグル、シマンテックが発行したTLS証明書に不信感 - CNET Japan</a></li>
</ul>
<p>「<a href="http://notchained.hatenablog.com/entry/2017/03/27/090554" title="Symantecが再びGoogleの信頼を失った件についてのメモ - Technically, technophobic.">Symantecが再びGoogleの信頼を失った件についてのメモ</a>」にもあるように Symantec (傘下の Thawte)は既に前科持ちなので「またか(sigh)」って感じなのだが…</p>
<p>X.509 型の公開鍵基盤は認証局(Certification Authority; CA)が信頼できることが絶対条件で,これが崩れると機能しなくなる。</p>
<p>喩えるならお金と銀行の関係と似ている。
銀行はお金の価値を担保するが銀行が信用できないのならお金の価値を担保するものがなくなる。
同じく認証局が管理する証明書は認証局が安全性を担保できているからこそ意味がある。
そうでなければオレオレ証明書またはそれ以下の価値しかない。</p>
<p>この問題は Symantec と Google の2者間の喧嘩だと思ったら物事を見誤る。
現在 Web を支配している公開鍵基盤の根幹に関わる問題なのである。</p>
<p>それにしても,昔「<a href="https://baldanders.info/blog/000277/" title="Extended Validation SSL — Baldanders.info">EV SSL は『屋上屋を架す』ようにしか見えない</a>」と書いたが,まったくもってその通りだったな(笑)</p>
<h2>ブックマーク</h2>
<ul>
<li><a href="https://baldanders.info/blog/000809/">Malware Spoofing HTTPS(3月2日,追記あり) — Baldanders.info</a></li>
<li><a href="https://baldanders.info/blog/000812/">HTTPS Deep Inspection — Baldanders.info</a></li>
<li><a href="https://japan.zdnet.com/article/35098402/">HTTPS監視装置にセキュリティ低下の危険性–日米機関で注意喚起 - ZDNet Japan</a></li>
<li><a href="https://www.schneier.com/blog/archives/2017/03/new_paper_on_en.html">New Paper on Encryption Workarounds - Schneier on Security</a>
<ul>
<li><a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2938033">Encryption Workarounds by Orin S. Kerr, Bruce Schneier :: SSRN</a></li>
</ul>
</li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t6yHHVwEL._SL160_.jpg" width="113" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号技術入門 第3版 秘密の国のアリス</a></dt>
<dd>結城 浩 (著)</dd>
<dd>SBクリエイティブ 2015-08-25 (Release 2015-09-17)</dd>
<dd>Kindle版</dd>
<dd>B015643CPE (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-09-20">2015-09-20</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号技術入門 第3版 -->
<div class="footnotes" role="doc-endnotes">
<hr>
<ol>
<li id="fn:1">
<p>念のため簡単に説明しておくと, HTTPS (Hypertext Transfer Protocol Secure) 暗号通信は WWW (World Wide Web) におけるクライアント-サーバ間の通信経路を暗号化する仕組みである。具体的には TLS (Transport Layer Security) 等のプロトコルを用い公開鍵暗号方式を使ってセッション鍵を生成する。また公開鍵暗号方式の公開鍵は X.509 方式の公開鍵基盤によって管理される。 <a href="#fnref:1" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
</ol>
</div>
OpenPGP に関する話題
tag:text.Baldanders.info,2017-03-05:/remark/2017/03/topics-on-openpgp/
2017-03-05T08:19:39+00:00
2022-05-04T05:22:29+00:00
GnuPG 2.1.19 がリリース / 映像の証明 / 電子メールの暗号化 / SHA-1 の危殆化と OpenPGP V5
Spiegel
https://baldanders.info/profile/
<p>さてさて。
2月も逃げちゃいましたよ。</p>
<ol>
<li><a href="#gpg">GnuPG 2.1.19 がリリース</a></li>
<li><a href="#pm">映像の証明</a></li>
<li><a href="#em">電子メールの暗号化</a></li>
<li><a href="#v5">SHA-1 の危殆化と OpenPGP V5</a></li>
</ol>
<h2 id="gpg">GnuPG 2.1.19 がリリース</h2>
<ul>
<li><a href="https://lists.gnupg.org/pipermail/gnupg-announce/2017q1/000402.html">[Announce] GnuPG 2.1.19 released</a></li>
</ul>
<p>セキュリティアップデートはなし。
主な修正・変更点は以下の通り。</p>
<ul>
<li>gpg: Print a warning if Tor mode is requested but the Tor daemon is not running.</li>
<li>gpg: New status code <code>DECRYPTION_KEY</code> to print the actual private key used for decryption.</li>
<li>gpgv: New options <code>--log-file</code> and <code>--debug</code>.</li>
<li>gpg-agent: Revamp the prompts to ask for card PINs.</li>
<li>scd: Support for multiple card readers.</li>
<li>scd: Removed option <code>--debug-disable-ticker</code>. Ticker is used only when it is required to watch removal of device/card.</li>
<li>scd: Improved detection of card inserting and removal.</li>
<li>dirmngr: New option <code>--disable-ipv4</code>.</li>
<li>dirmngr: New option <code>--no-use-tor</code> to explicitly disable the use of Tor.</li>
<li>dirmngr: The option <code>--allow-version-check</code> is now required even if the option <code>--use-tor</code> is also used.</li>
<li>dirmngr: Handle a missing nsswitch.conf gracefully.</li>
<li>dirmngr: Avoid PTR lookups for keyserver pools. The are only done for the debug command “<code>keyserver --hosttable</code>”.</li>
<li>dirmngr: Rework the internal certificate cache to support classes of certificates. Load system provided certificates on startup. Add options <code>--tls</code>, <code>--no-crl</code>, and <code>--systrust</code> to the “<code>VALIDATE</code>” command.</li>
<li>dirmngr: Add support for the ntbtls library.</li>
<li>wks: Create mails with a “WKS-Phase” header. Fix detection of Draft-2 mode.</li>
<li>The Windows installer is now build with limited TLS support.</li>
<li>Many other bug fixes and new regression tests.</li>
</ul>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">$ gpg --version
</span></span><span class="line"><span class="cl">gpg (GnuPG) 2.1.19
</span></span><span class="line"><span class="cl">libgcrypt 1.7.6
</span></span><span class="line"><span class="cl">Copyright (C) 2017 Free Software Foundation, Inc.
</span></span><span class="line"><span class="cl">License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
</span></span><span class="line"><span class="cl">This is free software: you are free to change and redistribute it.
</span></span><span class="line"><span class="cl">There is NO WARRANTY, to the extent permitted by law.
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl">Home: ********
</span></span><span class="line"><span class="cl">サポートしているアルゴリズム:
</span></span><span class="line"><span class="cl">公開鍵: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
</span></span><span class="line"><span class="cl">暗号方式: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
</span></span><span class="line"><span class="cl"> CAMELLIA128, CAMELLIA192, CAMELLIA256
</span></span><span class="line"><span class="cl">ハッシュ: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
</span></span><span class="line"><span class="cl">圧縮: 無圧縮, ZIP, ZLIB, BZIP2
</span></span></code></pre></div><h2 id="pm">映像の証明</h2>
<p><a href="https://guardianproject.info/" title="Guardian Project – People, Apps and Code You Can Trust">Guardian Project</a> が提供している <a href="https://guardianproject.info/apps/camerav/" title="CameraV: Secure Verifiable Photo & Video Camera – Guardian Project">CameraV</a> というカメラアプリがあるが,この中の Proof Mode という機能を有効にすることで写した写真やビデオの「証明」を作成することができるらしい。</p>
<ul>
<li><a href="https://guardianproject.info/2017/02/24/combating-fake-news-with-a-smartphone-proof-mode/">Combating “Fake News” With a Smartphone “Proof Mode” – Guardian Project</a></li>
<li><a href="https://www.schneier.com/blog/archives/2017/03/proof_mode_for_.html">“Proof Mode” for your Smartphone Camera - Schneier on Security</a></li>
</ul>
<figure lang="en">
<blockquote>
<q>On the technical front, what the app is doing is automatically generating an OpenPGP key for this installed instance of the app itself, and using that to automatically sign all photos and videos at time of capture. A sha256 hash is also generated, and combined with a snapshot of all available device sensor data, such as GPS location, wifi and mobile networks, altitude, device language, hardware type, and more. This is also signed, and stored with the media. All of this happens with no noticeable impact on battery life or performance, every time the user takes a photo or video.</q>
</blockquote>
<figcaption><div>via <q><a href="https://guardianproject.info/2017/02/24/combating-fake-news-with-a-smartphone-proof-mode/">Combating “Fake News” With a Smartphone “Proof Mode”</a></q></div></figcaption>
</figure>
<p>まぁ,いまどき映像であってもいくらでも捏造できるからねぇ。
こういう仕組みも必要になってくるというわけだ。
Proof Mode の設計目標は以下の通り。</p>
<ul>
<li>Run all of the time in the background without noticeable battery, storage or network impact</li>
<li>Provide a no-setup-required, automatic new user experience that works without requiring training</li>
<li>Use strong cryptography for strong identity and verification features, but not encryption</li>
<li>Produce “proof” sensor data formats that can be easily parse, imported by existing tools (CSV)</li>
<li>Do not modify the original media files; all proof metadata storied in separate file</li>
<li>Support chain of custody needs through automatic creation of sha256 hashes and PGP signatures</li>
<li>Do not require a persistent identity or account generation</li>
</ul>
<p>内部では映像毎に OpenPGP 電子署名を作成するが,鍵の生成や運用は自動でやってくれるようだ。
便利。
なのだが,イマイチ使い勝手がよく分からない。
使い方はおいおい覚えていくとしよう。</p>
<p>ちなみに <a href="https://guardianproject.info/apps/camerav/" title="CameraV: Secure Verifiable Photo & Video Camera – Guardian Project">CameraV</a> では撮った映像を暗号化したり panic 時に映像を全部消去できたりする機能もあるらしい。
最近いろいろ物騒だからねぇ。</p>
<ul>
<li><a href="https://techcrunch.com/2016/12/14/photojournalists-demand-encryption-light-is-giving-it-to-them/">フォトジャーナリストたちがプロ用カメラに暗号化機能を求めた | TechCrunch Japan</a></li>
<li><a href="https://techcrunch.com/2016/12/14/onpx-n-ovg-onpx-n-ovg-zber/">暗号化機能をカメラに追加しても写真ジャーナリストたちの問題は解決しない | TechCrunch Japan</a></li>
</ul>
<h2 id="em">電子メールの暗号化</h2>
<p>ここのところ暗号化電子メールの話題をよく見かける。</p>
<ul>
<li><a href="https://japan.zdnet.com/article/35097359/">グーグルのメール暗号化Chromeアプリケーション「E2EMail」がオープンソースに - ZDNet Japan</a></li>
<li><a href="http://getnews.jp/archives/1638152">Android版Gmail v7.2でS/MIMEの暗号化機能をサポート | ガジェット通信</a></li>
<li><a href="https://japan.techrepublic.com/article/35097236.htm">「Chromebook」で効率的に電子メールを暗号化する方法–「K-9 Mail」と「APG」を利用 - TechRepublic Japan</a></li>
</ul>
<p>「<a href="https://japan.zdnet.com/article/35097359/">グーグルのメール暗号化Chromeアプリケーション「E2EMail」がオープンソースに</a>」の最後の方に出てくる <a href="https://security.googleblog.com/2017/01/security-through-transparency.html" title="Google Online Security Blog: Security Through Transparency">Key Transparency</a> については以前に本家サイトで紹介したので参考にどうぞ。</p>
<ul>
<li><a href="https://baldanders.info/blog/000785/">Google による OpenPGP 鍵配送の解決提案 — Baldanders.info</a></li>
</ul>
<p>個人的には(OpenPGP ではないが)「<a href="http://getnews.jp/archives/1638152">Android版Gmail v7.2でS/MIMEの暗号化機能をサポート</a>」のほうに注目している。
S/MIME は X.509 型の PKI で鍵を運用するもので Web メールやケータイアプリでの鍵管理がやりやすいのが特徴。
こちらは暗号化より電子署名によるメールの証明がやりやすくなるのではないだろうか。</p>
<p>企業からのプロモーションメールを S/MIME 形式で電子署名することによって HTTPS の EV SSL と同様な効果が狙えると思う。
S/MIME 形式で電子署名が一般的になれば spam メールの排除もやりやすくなるかもしれない。</p>
<p>電子署名ではなく暗号化メールでいうなら,当面は <a href="https://protonmail.com/" title="Secure email: ProtonMail is free encrypted email.">ProtonMail</a> をお勧めする。</p>
<ul>
<li><a href="https://techcrunch.com/2016/11/11/signups-for-encrypted-mail-client-protonmail-double-after-election/">暗号化メールサービスProtonMailの新規ユーザーが選挙後に急増、トランプ新大統領の不寛容を懸念 | TechCrunch Japan</a></li>
</ul>
<p>私もしばらく前にアカウントを作っている。</p>
<ul>
<li><a href="https://text.baldanders.info/remark/2016/03/protonmail/">ProtonMail のアカウントを作りました</a></li>
</ul>
<h2 id="v5">SHA-1 の危殆化と OpenPGP V5</h2>
<p>現在の OpenPGP は鍵指紋に SHA-1 を使用しているが, <a href="https://text.baldanders.info/remark/2017/02/sha-1-collision/">SHA-1 の危殆化</a>に伴い「どーする?」ってな議論になってるようだ。</p>
<ul>
<li><a href="https://mailarchive.ietf.org/arch/msg/openpgp/_uV_coJ0CYayv_2ptJMuSraJhws">[openpgp] V5 Fingerprint again</a></li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t6yHHVwEL._SL160_.jpg" width="113" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号技術入門 第3版 秘密の国のアリス</a></dt>
<dd>結城 浩 (著)</dd>
<dd>SBクリエイティブ 2015-08-25 (Release 2015-09-17)</dd>
<dd>Kindle版</dd>
<dd>B015643CPE (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-09-20">2015-09-20</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号技術入門 第3版 -->
週末スペシャル: まじめに規制に従っている人ほど馬鹿を見る社会
tag:text.Baldanders.info,2016-04-10:/remark/2016/04/10-stories/
2016-04-10T09:44:29+00:00
2022-05-04T05:22:29+00:00
まじめに規制に従っている人ほど馬鹿を見る社会 / Linux サブシステムは Windows の終わりの始まり / 鍵管理システム CONIKS / Go 言語を使うようになって変わったこと / その他の気になる記事
Spiegel
https://baldanders.info/profile/
<p>3月は去りました。
春になっちゃったよ。</p>
<p>うっかり左手首を痛めてしまった(疲労がたまるとたまになる)のでいろいろ控えてた。
溜まりまくった小ネタを消化しないと。</p>
<ol>
<li><a href="#code">まじめに規制に従っている人ほど馬鹿を見る社会</a></li>
<li><a href="#bash">Linux サブシステムは Windows の終わりの始まり</a></li>
<li><a href="#pki">鍵管理システム CONIKS</a></li>
<li><a href="#go">Go 言語を使うようになって変わったこと</a></li>
<li><a href="#other">その他の気になる記事</a></li>
</ol>
<h2 id="code">まじめに規制に従っている人ほど馬鹿を見る社会</h2>
<p>もう何度も書いているが「警察にできることは犯罪者にもできる」。
問題は犯罪者にできることが警察にもできるかどうか駄菓子菓子…</p>
<ul>
<li><a href="http://japan.cnet.com/news/society/35080404/">米政府によるスマホデータ取り出しの協力要請、ACLUが実態調査 - CNET Japan</a></li>
<li><a href="http://www.itmedia.co.jp/news/articles/1604/01/news114.html">FBIのiPhoneロック解除方法、Appleに知らされない可能性も (1/3) - ITmedia ニュース</a></li>
<li><a href="http://www.itmedia.co.jp/news/articles/1604/08/news060.html">FBI長官、「購入したロック解除ツールはiPhone 5sでは機能しなかった」 - ITmedia ニュース</a></li>
<li><a href="https://techcrunch.com/2016/04/08/justice-department-keeps-pushing-apple-to-unlock-iphone-in-new-york-drug-case/">司法省がまたAppleにiPhoneアンロック要求、今度はAppleが“相手を間違えた”国を訴訟か | TechCrunch Japan</a></li>
</ul>
<p>FBI が端末を突破するのに外部企業を使ったということ,そして企業がそれに応じたことは重要だ。
もちろん実は NSA の息のかかった企業だった,としても驚かないけど。</p>
<p>企業は利があると思えば警察にも犯罪者にだって加担する。
今回の件のポイントは「犯罪者にできることが警察にできるとは限らない」と証明してしまったことだ。
セキュリティ企業は新しい時代の「死の商人」になるかもしれない。</p>
<p>警察が優位に立てるのは犯罪者よりもパワー(暴力・権力を含む)を有している場合のみである。
コンピュータ・ネットワーク技術あるいは暗号技術において政府・警察は優位に立てない。
米国司法省は法規制によって優位に立てると思ってるようだが,こんなもの最初から「法の外」にいる犯罪者やテロリストに対しては効力がない。</p>
<ul>
<li><a href="http://www.itmedia.co.jp/news/articles/1604/09/news022.html">暗号化解除をめぐる米法案、司法当局へのバックドア提供を義務付け - ITmedia ニュース</a></li>
<li><a href="http://japan.cnet.com/news/society/35080962/">バックドア提供を拒む企業に制裁金を–米国で法案が公開 - CNET Japan</a></li>
</ul>
<p>これは「飲酒運転を減らすために飲酒運転規制を厳罰化する」というのとは話が違う。
犯罪者にはインパクトがないし,まじめに規制に従っている人ほど「馬鹿を見る」ことになる。</p>
<p>有害なルールに従う必要はないし,それに従うことはむしろリスクを高めることになる。</p>
<h2 id="bash">Linux サブシステムは Windows の終わりの始まり</h2>
<ul>
<li><a href="https://techcrunch.com/2016/03/30/be-very-afraid-hell-has-frozen-over-bash-is-coming-to-windows-10/">Build 2016で驚きの発表―Microsoftはこの夏Windows 10でBashシェルをサポート | TechCrunch Japan</a></li>
<li><a href="http://japan.cnet.com/news/service/35080406/">「Windows 10」で動作するUbuntuのBashシェル–その実現方法 - CNET Japan</a></li>
<li><a href="https://satonaoki.wordpress.com/2016/03/31/bash-ubuntu-windows/">開発者がWindows 10でBashシェルとユーザー モードのUbuntu Linuxバイナリを実行可能に | S/N Ratio (by SATO Naoki)</a></li>
<li><a href="http://www.publickey1.jp/blog/16/mariadbmariadb_columnstoreolap.html">MariaDB、カラム型データベースエンジン「MariaDB ColumnStore」発表。OLAPへ参入 - Publickey</a></li>
</ul>
<p><del>もともと Windows は POSIX サブシステムを持っている。
今回はそれに加えて</del> Ubuntu ベースの Linux サブシステムを組み込むということらしいが子亀の上に親亀を乗っけるようなものだ。</p>
<p>Windows の基本的な設計思想は20~25年くらい前の古いものだ。
しかも DOS/Windows はもともとシングルユーザ用に設計されたもので UNIX 等のマルチユーザ向けの OS とは全く異なる。</p>
<p>Linux のベースとなっている UNIX もそうとう古いが,マルチユーザを前提とした考え方は今でも通用するし,なにより Linux はもはや UNIX に縛られない。</p>
<ul>
<li><a href="http://d.hatena.ne.jp/yomoyomo/20160331/linux25years">Linux公開25周年を受けたリーナス・トーバルズのインタビュー - YAMDAS現更新履歴</a></li>
<li><a href="http://japan.zdnet.com/article/35080722/">Linux創始者トーバルズ氏、IoTを語る–「セキュリティは二の次」と警鐘 - ZDNet Japan</a></li>
</ul>
<p>Windows は永遠に Windows に縛られ続ける。
Microsoft が満を持して出した Windows 10 も結局は Windows に縛られている。</p>
<p>Windows が時代遅れなのは明らかである。
Microsoft 自らこういう無茶をすること自体が「Windows の終わりの始まり」だ。
個人的に2020年までに自宅 PC のメインを Linux 機に換装する予定だが,ちょっと計画を前倒ししたほうがいいかもしれない。</p>
<ul>
<li><a href="http://japan.zdnet.com/article/35080364/">目的別のおすすめLinuxディストリビューション–あなたにぴったりなのはどれ? - ZDNet Japan</a></li>
</ul>
<h3>追記</h3>
<ul>
<li><a href="http://mattn.kaoriya.net/software/why-i-use-cmd-on-windows.htm">Big Sky :: Windows ユーザは cmd.exe で生きるべき。</a></li>
</ul>
<p>激しく同意。
もっとも私は <a href="https://text.baldanders.info/remark/2015/conemu-and-nyagos/">ConEmu & NYAGOS</a> だけど(笑)</p>
<h2 id="sig">WhatsApp がついに Signal ベースの E2E 暗号化を実装する</h2>
<ul>
<li><a href="https://whispersystems.org/blog/whatsapp-complete/">Open Whisper Systems » Blog » WhatsApp’s Signal Protocol integration is now complete</a></li>
<li><a href="http://techcrunch.com/2016/04/05/whatsapp-completes-end-to-end-encryption-rollout/">WhatsApp completes end-to-end encryption rollout | TechCrunch</a></li>
<li><a href="http://www.itmedia.co.jp/news/articles/1604/06/news069.html">Facebook傘下のWhatsApp、完全暗号化を完了 「政府もわれわれも解除できない」 - ITmedia ニュース</a></li>
<li><a href="https://techcrunch.com/2016/04/05/whatsapp-completes-end-to-end-encryption-rollout/">WhatsApp、全てのプラットフォームのエンドツーエンド暗号化を完了 | TechCrunch Japan</a></li>
</ul>
<p>もともと WhatsApp が Signal ベースの暗号化システムを実装することは予告されていた。</p>
<ul>
<li><a href="https://whispersystems.org/">Open Whisper Systems</a> (<a href="https://github.com/WhisperSystems">GitHub</a>)
<ul>
<li><a href="http://support.whispersystems.org/hc/en-us/articles/212477768-Is-it-secure-Can-I-trust-it-">Is it private? Can I trust it? – Support</a></li>
</ul>
</li>
</ul>
<p>Signal 自体は SMS アプリを置き換えることのできる優れたアプリなのだが SNS ベースのメッセンジャー・アプリとしては機能的に劣る。
WhatsApp がその辺を埋めることになるかどうか。
でも日本のユーザにはウケないかなぁ。</p>
<p>メールは ProtonMail, SMS ベースのメッセンジャーには Signal,それ以外のメッセンジャーには WhatsApp と,だいぶ揃ってきたねぇ。</p>
<h2 id="pki">鍵管理システム CONIKS</h2>
<ul>
<li><a href="https://coniks.cs.princeton.edu/">CONIKS</a></li>
<li><a href="https://www.schneier.com/blog/archives/2016/04/coniks.html">CONIKS - Schneier on Security</a></li>
</ul>
<figure lang="en">
<blockquote>
<q>CONIKS is a key management system for end users capable of integration in end-to-end secure communication services. The main idea is that users should not have to worry about managing encryption keys when they want to communicate securely, but they also should not have to trust their secure communication service providers to act in their interest.</q>
</blockquote>
<figcaption><div>via <q><a href="https://coniks.cs.princeton.edu/">CONIKS</a></q></div></figcaption>
</figure>
<p>とりあえずメーリング・リストに入ってみた。</p>
<h2 id="go">Go 言語を使うようになって変わったこと</h2>
<p>内容自体にさほど文句があるわけではないが(細かい部分は置いておいて),「interface を中心に設計する」という記述が気になって。</p>
<script async class="speakerdeck-embed" data-id="947e9a6ef68c4310baf21afdec4fcfab" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
<p>私はそんなにたくさんの言語を知っているわけではないが, <a href="https://golang.org/" title="The Go Programming Language">Go 言語</a>を勉強するようになって設計の考え方が少し変わった。
まさに「制約は構造を生む」(by 結城浩「数学ガール」シリーズより)が如く,言語仕様によって思考も影響を受けるのである。
以下にいくつか例を挙げよう。</p>
<h3>Value Object から考える</h3>
<p>さて,いつもの図。</p>
<figure style='margin:0 auto;text-align:center;'><a href="./DDD.svg"><img src="./DDD.svg" srcset="./DDD.svg 640w" sizes="(min-width:600px) 500px, 80vw" alt="Domain-Driven Design" loading="lazy"></a><figcaption><div><a href="./DDD.svg">Domain-Driven Design</a></div></figcaption>
</figure>
<p>Domain Layer の中身は Domain Service, Entity, そして Value Object に分類される。
ビジネスロジックは図の右側,つまり Entity や Value Object に記述されるのが良い設計だと言われている(記述の重複を避けられるため)。
ただし Value Object はしばしば省略されることが多い。</p>
<p>Value Object の特徴は以下のとおり。</p>
<ul>
<li>内部状態を持たず不変である</li>
<li>属性(property)の比較のみでオブジェクト同士が等価かどうか決定できる</li>
</ul>
<p>そして実装上の要件としては「軽量」であることが求められる。
何故なら Value Object は Entity の属性として使われることが多く Value Object がボトルネックになるとシステム全般へのインパクトが大きいからだ。</p>
<p>実は <a href="https://golang.org/" title="The Go Programming Language">Go 言語</a>はこの Value Object の実装にとても向いている。</p>
<ul>
<li><a href="https://text.baldanders.info/golang/object-oriented-programming/">Go 言語における「オブジェクト」 — プログラミング言語 Go</a></li>
<li><a href="https://text.baldanders.info/golang/function-and-pointer/">関数とポインタ — プログラミング言語 Go</a></li>
</ul>
<p><a href="https://golang.org/" title="The Go Programming Language">Go 言語</a>の特徴である「強い型付け」も Value Object を念頭に置いて考えるなら合理的な仕様であることが分かるだろう。</p>
<h3>多態性を「振る舞い」から考える</h3>
<p><a href="https://golang.org/" title="The Go Programming Language">Go 言語</a>の多態性(polymorphism)は振る舞いによってのみ規定される(構造的部分型)。
つまり「猫」のように振る舞うのであれば実体がロボットだろうがコスプレイヤーだろうが全部「猫」として括れるのである。
そして「猫」のようにあるためにロボットやコスプレイヤーの identity を書き換える必要はない。
これはとても重要な事である。</p>
<p>たとえば「猫」を実装する際に,それに多態性を持たせなければならないかどうかは設計の割と早い段階で決めなければならないことが多い。
そうして先に <code>interface</code> などを決めなければ具体的なクラスを記述することができない。
しかし <a href="https://golang.org/" title="The Go Programming Language">Go 言語</a>ではアプローチが逆になる。
先にロボットやコスプレイヤーといった具体的な型(<a href="https://go.dev/ref/spec#Properties_of_types_and_values" title="Properties of types and values">type</a>)をバンバン作り,個々の振る舞いを見て,あとから「あっ,これ「猫」で括れるぢゃん♥」となるわけだ。
言い方を変えるなら refactoring 向きであるとも言える。</p>
<h3>要件定義からコードを書く</h3>
<p>これは <a href="https://golang.org/" title="The Go Programming Language">Go 言語</a>に限らないが, refactoring しやすい言語は prototyping に向いている言語であるとも言える。
Prototyping に向いているということはプロジェクトのかなり早い段階(たとえば要件定義)からコードを書けるということでもある。
結局エンジニアにとって信用できるのは百万語を連ねた設計書より「動くコード」なのである。</p>
<h2 id="other">その他の気になる記事</h2>
<ul>
<li><a href="https://torrentfreak.com/transmission-releases-long-awaited-bittorrent-client-for-windows-160327/">Transmission Releases Long-Awaited BitTorrent Client For Windows - TorrentFreak</a></li>
<li><a href="http://postd.cc/npm-and-left-pad/">NPMとleft-pad : 私たちはプログラミングのやり方を忘れてしまったのか? | プログラミング | POSTD</a></li>
<li><a href="https://techcrunch.com/2016/03/28/windows-users-finally-have-a-good-bittorrent-client/">WindowsにBitTorrentクライアントの決定版Transmissionがやってくる | TechCrunch Japan</a></li>
<li><a href="http://www.iij.ad.jp/news/pressrelease/2016/0329-2.html">IIJ、Webサイトにおけるユーザ認証のセキュリティを強化する 「IIJ SmartKeyマネージメントサービス」を提供開始 | 2016年 | IIJ</a></li>
<li><a href="http://www.ipa.go.jp/security/technicalwatch/201600330.html">IPAテクニカルウォッチ「公衆無線LAN利用に係る脅威と対策」:IPA 独立行政法人 情報処理推進機構</a></li>
<li><a href="https://www.jpcert.or.jp/research/apt-guide.html">高度サイバー攻撃(APT)への備えと対応ガイド~企業や組織に薦める一連のプロセスについて</a></li>
<li><a href="http://p2ptk.org/copyright/231">著作権削除要請の28%が「疑わしい」との研究結果 – P2Pとかその辺のお話R</a></li>
<li><a href="http://current.ndl.go.jp/node/31200">国立極地研究所情報図書室、ウェブサイトをCC BYで公開 | カレントアウェアネス・ポータル</a></li>
<li><a href="http://fanfun.jaxa.jp/jaxatv/files/20160408_hitomi.pdf">X線天文衛星「ひとみ」(ASTRO-H)の状況について - 20160408_hitomi.pdf</a>
<ul>
<li><a href="http://sorae.jp/030201/2016_04_02_jspoc.html">X線天文衛星「ひとみ」、回転は破片を誤認?米軍発表 | Sorae.jp : 宇宙(そら)へのポータルサイト</a></li>
</ul>
</li>
<li><a href="https://medium.com/@tsukamoto/-f42bf7b5e25e">定時帰宅のススメ — Medium</a></li>
<li><a href="https://techcrunch.com/2016/04/08/spacex-just-landed-a-rocket-on-a-drone-ship-for-the-first-time/">SpaceXのFalcon 9ロケット、洋上のドローン艀への軟着陸についに成功 | TechCrunch Japan</a></li>
<li><a href="http://sonickun.hatenablog.com/entry/2016/04/03/183220">GoogleがTLSでの採用を提唱している共通鍵暗号方式「ChaCha」についてまとめた - sonickun.log</a></li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B099928SJD?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/416Stewy0NS._SL160_.jpg" width="123" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B099928SJD?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">プログラミング言語Go</a></dt>
<dd>アラン・ドノバン (著), ブライアン・カーニハン (著), 柴田芳樹 (著)</dd>
<dd>丸善出版 2016-06-20 (Release 2021-07-13)</dd>
<dd>Kindle版</dd>
<dd>B099928SJD (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">Kindle 版出た! 一部内容が古びてしまったが,この本は Go 言語の教科書と言ってもいいだろう。感想は<a href="https://text.baldanders.info/remark/2016/07/go-programming-language/" >こちら</a>。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2021-05-22">2021-05-22</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- プログラミング言語Go -->