List of Trust - text.Baldanders.info
tag:text.Baldanders.info,2023-12-05:/tags
2023-12-05T22:01:31+09:00
帰ってきた「しっぽのさきっちょ」
https://text.baldanders.info/images/avatar.jpg
https://text.baldanders.info/images/avatar.jpg
「人工知能と信頼」〜 鉄腕アトムとは友達になれない
tag:text.Baldanders.info,2023-12-05:/remark/2023/12/ai-and-trust/
2023-12-05T13:01:31+00:00
2023-12-16T03:32:25+00:00
我らが Bruce Schneier 先生の最新エッセイが面白かったので紹介するふりをして戯れ言を書いてみる。
Spiegel
https://baldanders.info/profile/
<p>我らが Bruce Schneier 先生の最新エッセイが面白かったので紹介するふりをして戯れ言を書いてみる。</p>
<ul>
<li><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust - Schneier on Security</a></li>
</ul>
<p>このエッセイでは以下の4つの内容について取り上げている。</p>
<ol>
<li>信頼には対人信頼(interpersonal trust)と社会的信頼(social trust)の2つがあり,私達はしばしば両者を混同してしまう</li>
<li>人工知能(AI)によってこの混同が拡大する</li>
<li>AI システムを管理している企業はこの混同に便乗して私達を利用する</li>
<li>社会への信頼を生み出すのが政府の役割(=規制)である</li>
</ol>
<p>その上で</p>
<figure lang="en">
<blockquote>Not regulating AI, but regulating the organizations that control and use AI.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>と言うのだ。
もうのっけから面白い!</p>
<p>まずは対人信頼(interpersonal trust)について。</p>
<figure lang="en">
<blockquote>When we say that we trust a friend, it is less about their specific actions and more about them as a person. IIt’s a general reliance that they will behave in a trustworthy manner. We trust their intentions, and know that those intentions will inform their actions. Let’s call this “interpersonal trust.”</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>つまり「◯◯さんは人として信頼できる」というのが対人信頼なわけだ。
それに対し,社会的信頼(social trust)については</p>
<figure lang="en">
<blockquote>We might not know someone personally, or know their motivations—but we can trust their behavior. We don’t know whether or not someone wants to steal, but maybe we can trust that they won’t. It’s really more about reliability and predictability. We’ll call this “social trust.” It’s the ability to trust strangers.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>と書かれている。
たとえば企業が「顧客サービスは信頼が大事」などというときの「信頼」は対人信頼ではなく社会的信頼ということだ。
そして</p>
<figure lang="en">
<blockquote>Because of how large and complex society has become, we have replaced many of the rituals and behaviors of interpersonal trust with security mechanisms that enforce reliability and predictability—social trust.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>と続く。
しかし対人信頼と社会的信頼はひと括りに「信頼」と呼んでるため両者を混同してしまう。
カテゴリーエラーが発生するわけだ。</p>
<figure lang="en">
<blockquote>We might think of them as friends, when they are actually services. Corporations are not moral; they are precisely as immoral as the law and their reputations let them get away with.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>私は上に引用した文章で爆笑してしまったよ。
企業は法律と同じくらい非道徳的だってさ。
言われてみればそうだよね(笑)</p>
<figure lang="en">
<blockquote>Corporations like that we make this category error—see, I just made it myself—because they profit when we think of them as friends. They use mascots and spokesmodels. They have social media accounts with personalities. They refer to themselves like they are people.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>ここでようやく AI が出てくる。</p>
<figure lang="en">
<blockquote>Science fiction author Ted Chiang writes about it. Instead of solving all of humanity’s problems, or wandering off proving mathematical theorems that no one understands, the AI single-mindedly pursues the goal of maximizing production. Chiang’s point is that this is every corporation’s business plan. And that our fears of AI are basically fears of capitalism.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<figure lang="en">
<blockquote>And near-term AIs will be controlled by corporations. Which will use them towards that profit-maximizing goal. They won’t be our friends. At best, they’ll be useful services. More likely, they’ll spy on us and try to manipulate us.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>そして,企業に制御される AI は以下の2つの理由で悪い方向に転ぶと予測する。</p>
<figure lang="en">
<blockquote>The first is that these AI systems will be more relational. We will be conversing with them, using natural language. As such, we will naturally ascribe human-like characteristics to them.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<figure lang="en">
<blockquote>The second reason to be concerned is that these AIs will be more intimate. One of the promises of generative AI is a personal digital assistant. Acting as your advocate with others, and as a butler with you.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>その結果</p>
<figure lang="en">
<blockquote>It’s no accident that these corporate AIs have a human-like interface. There’s nothing inevitable about that. It’s a design choice. It could be designed to be less personal, less human-like, more obviously a service—like a search engine . The companies behind those AIs want you to make the friend/service category error. It will exploit your mistaking it for a friend. And you might not have any choice but to use it.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>私達は AI によって「信頼」を混同したまま強制されるわけだ。</p>
<figure lang="en">
<blockquote>Corporations are profit maximizers, at the expense of society. And the incentives of surveillance capitalism are just too much to resist.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>そして,これに規制をかけるのは政府の役割となる。</p>
<figure lang="en">
<blockquote>The more you can trust that your societal interactions are reliable and predictable, the more you can ignore their details. Places where governments don’t provide these things are not good places to live.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>“not good places to live” って今の日本社会のことか(笑)</p>
<p>それはともかく</p>
<figure lang="en">
<blockquote>Government can do this with AI. We need AI transparency laws. When it is used. How it is trained. What biases and tendencies it has. We need laws regulating AI—and robotic—safety. When it is permitted to affect the world. We need laws that enforce the trustworthiness of AI. Which means the ability to recognize when those laws are being broken. And penalties sufficiently large to incent trustworthy behavior.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>そのために多くの国が AI 規制について議論しているが,そこに大きな間違いがあるという。
つまり</p>
<figure lang="en">
<blockquote>Many countries are contemplating AI safety and security laws—the EU is the furthest along—but I think they are making a critical mistake. They try to regulate the AIs and not the humans behind them.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>ということだ。
何故なら AI は人間ではないから。</p>
<figure lang="en">
<blockquote>AIs are not people; they don’t have agency. They are built by, trained by, and controlled by people. Mostly for-profit corporations. Any AI regulations should place restrictions on those people and corporations. Otherwise the regulations are making the same category error I’ve been talking about. At the end of the day, there is always a human responsible for whatever the AI’s behavior is. And it’s the human who needs to be responsible for what they do—and what their companies do. Regardless of whether it was due to humans, or AI, or a combination of both.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>AI とは友達になれない。
でも AI を善いサービスにすることはできる。</p>
<figure lang="en">
<blockquote>We can never make AI into our friends. But we can make them into trustworthy services—agents and not double agents. But only if government mandates it. We can put limits on surveillance capitalism. But only if government mandates it.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>そのための政府ってことだよね。</p>
<figure lang="en">
<blockquote>To the extent a government improves the overall trust in society, it succeeds. And to the extent a government doesn’t, it fails.</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html">AI and Trust</a></q></div></figcaption>
</figure>
<p>あれ? やっぱり日本政府って失敗してる?</p>
<p>このエッセイを読みながら5年前に書いた記事を思い出してた。</p>
<figure>
<blockquote>Amazon や Google などが提供する AI アシスタントの最大の問題はユーザがコントロールできないことにある。
喩えるなら百貨店の外商がリアルタイムで店と連携をとりつつ24時間家の中に張り付いているようなものだ。
「外商」が忠誠を誓うのは所属する店であり,客との関係は利害の一致を基本とした信頼関係に過ぎない。
これが「執事」なら向きが逆になる。
「執事」は主人に忠誠を誓うからこそ執事として機能するし主人は執事をコントロールできる。</blockquote>
<figcaption><div><q><a href="https://text.baldanders.info/remark/2018/04/ai-assistant/">AI アシスタントはユーザをアシストしない</a></q>より</div></figcaption>
</figure>
<p>結局そこに帰着するんだよなぁ。</p>
<p>そうそう。
関係ないが <del>「地上最大のロボット」</del> じゃない「PLUTO」のアニメ版が Netflix で公開されているらしい。
当時コミックをあれほど<a href="https://baldanders.info/spiegel/log/200605.html#d07_t2">絶賛した</a>のに,アニメはまだ観てないとか。
平日はアニメを観る気がしなくて,週末はチャリンコを乗り回して遊んでるので,やっぱりアニメは観なくなった。
このまま年を越してしまうのか…</p>
<h2>ブックマーク</h2>
<ul>
<li><a href="https://www.schneier.com/blog/archives/2023/12/ai-and-mass-spying.html">AI and Mass Spying - Schneier on Security</a></li>
<li><a href="https://wirelesswire.jp/2023/12/85735/">オープンソースの失われた10年と「オープンソースAI」の行方 – WirelessWire News</a></li>
<li><a href="https://text.baldanders.info/remark/2023/12/internet-as-a-monolithic-intelligence/">インターネットという単一知性</a></li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/4757143044?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/413qoSjODUL._SL160_.jpg" width="108" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/4757143044?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">信頼と裏切りの社会</a></dt>
<dd>ブルース・シュナイアー (著), 山形 浩生 (翻訳)</dd>
<dd>NTT出版 2013-12-24</dd>
<dd>単行本(ソフトカバー)</dd>
<dd>4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (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">社会における「信頼」とは。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-11-28">2015-11-28</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/B01MZGVHOA?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51T6PBdGbyL._SL160_.jpg" width="108" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B01MZGVHOA?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">超監視社会</a></dt>
<dd>ブルース・シュナイアー (著), 池村 千秋 (翻訳)</dd>
<dd>草思社 2016-12-13 (Release 2017-02-03)</dd>
<dd>Kindle版</dd>
<dd>B01MZGVHOA (ASIN)</dd>
</dl>
<p class="description">実は積ん読のまま読んでない。そろそろちゃんと最後まで読まないと。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2019-03-23">2019-03-23</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/B0CK19L1HC?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/41iX72RfUuL._SL160_.jpg" width="108" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B0CK19L1HC?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">ハッキング思考 強者はいかにしてルールを歪めるのか、それを正すにはどうしたらいいのか</a></dt>
<dd>ブルース・シュナイアー (著), 高橋 聡 (翻訳)</dd>
<dd>日経BP 2023-10-12 (Release 2023-10-12)</dd>
<dd>Kindle版</dd>
<dd>B0CK19L1HC (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 版が出てた!</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2023-11-21">2023-11-21</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- ハッキング思考 Kindle 版 -->
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B0BHYJKB5N?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51gl1i9n+WL._SL160_.jpg" width="113" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B0BHYJKB5N?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">PLUTO デジタルVer.(1) (ビッグコミックス)</a></dt>
<dd>浦沢直樹×手塚治虫 (著), 長崎尚志プロデュース (著), 手塚プロダクション (著), 手塚眞 (読み手)</dd>
<dd>小学館 2004-09-30 (Release 2022-10-28)</dd>
<dd>Kindle版</dd>
<dd>B0BHYJKB5N (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">今までの浦沢直樹さんの作品の中で一番なんじゃないだろうか。地上最大のロボット」って実はあまり印象にないんだよねぇ。全集なんかで読み返すと当時は(時代を反映した)結構な問題作だったらしいが,敢えてそれを選ぶってのが凄いよなぁ。オリジナルのラストはちょっと切ないというか物足りない終わり方をしているのだが,浦沢版ではいったいどうなるのか。楽しみである。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2006-05-07">2006-05-07</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- PLUTO -->
人の靭性
tag:text.Baldanders.info,2021-10-23:/remark/2021/10/toughness-of-system/
2021-10-23T10:43:26+00:00
2021-10-23T10:44:14+00:00
本の紹介を兼ねてちょろんと書いておく。
Spiegel
https://baldanders.info/profile/
<p>Twitter での脊髄反射 tweet に微妙に反応があったみたいなので,本の紹介を兼ねてちょろんと書いておく。</p>
<p>セキュリティ・システムにおける「<ruby><rb>靭性</rb><rp> (</rp><rt>じんせい</rt><rp>) </rp></ruby>」への言及を見かけたのは我らが Bruce Schneier 先生の『<a href="https://www.amazon.co.jp/dp/4822283100?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1" title="セキュリティはなぜやぶられたのか | ブルース・シュナイアー, 井口 耕二 |本 | 通販 | Amazon">セキュリティはなぜやぶられたのか</a>』第9章である。
ちょっと引用してみよう。</p>
<figure>
<blockquote><q>セキュリティシステムには障害がよくおきるので、障害の性質を理解することが大事である。硬直し剛性が高いシステムは悲惨な障害がおき、靭性が高くねばり強いシステムはうまく壊れていく。靭性の高いシステムは変化することができる。障害が一部にとどまったり、少しずつ劣化したりする。あるいは環境の変化に対応できる。自動化されたシステムは、基本的に剛性が高く、ひとつのことしかできない。部分的な障害や想定外の攻撃、新しい攻撃方法、ずるい攻撃者などに対応できないのだ。画一的や秘密に強く依存するシステムも剛性が高くなりがちで、その秘密が漏れると一気に潰れたりする</q></blockquote>
<figcaption><div><q><a href="https://www.amazon.co.jp/dp/4822283100?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">セキュリティはなぜやぶられたのか</a></q>より</div></figcaption>
</figure>
<p>このように「システムの壊れ方」について 剛性⇔靭性 という対比で説明している。
具体例については書籍を見ていただきたいが,この説明の後,第10章「セキュリティの中心は人である」に続くわけだ。</p>
<figure>
<blockquote><q>システムを機能させるためには一部の人を信頼しなければならない。そのような人々—信頼を託される人々—は、セキュリティシステムの一部だといえる。重要な構成要素、いや要となる要素だといえるだろう。システムで最も靭性が高い部分であり、臨機応変の対応や即断即決ができる部分であり、攻撃者の存在を感じとる能力が最も高い部分だからだ。しかし一方、セキュリティシステムの構成要素として考えたとき、人間な両刃の剣である。居眠りもすれば気がそれることもある。だまされることもある。敵側に寝返ることさえある。すぐれたセキュリティシステムとするためには信頼を託す人の長所を活用するとともに、信用が乱用されない防止策を講じなければならない</q></blockquote>
<figcaption><div><q><a href="https://www.amazon.co.jp/dp/4822283100?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">セキュリティはなぜやぶられたのか</a></q>より</div></figcaption>
</figure>
<p>「人はセキュリティの最弱点」とはよく言われるが,システムの 剛性⇔靭性 の対比で考えた場合は,人はセキュリティの最強点にもなり得る。
ある意味で最後の切り札(ace in the hole)と言ってもいいかも知れない。</p>
<figure>
<blockquote><q>最近は、技術力でセキュリティ問題を解決できると信じ、技術によって人を減らそうという傾向がある […] しかし人を技術で置き換えると、人が持つ創造性や創意工夫、適応力が利用できなくなる。人間がすることに制限を加えすぎると、人は無気力となり、同じ状況が生まれる。技術側では、人とその行動を非現実的なほどに理想化してしまう傾向がある。人は同じことしかしない、するはずのことを必ずして、するはずのないことはしないと仮定してしまうのだ。しかし実際には、そんな一定の行動を人がするはずがない。同時に、そんな融通が利かないこともない。技術的な対策は剛性が高く、障害がおきると大変なことになることが多い</q></blockquote>
<figcaption><div><q><a href="https://www.amazon.co.jp/dp/4822283100?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">セキュリティはなぜやぶられたのか</a></q>より</div></figcaption>
</figure>
<p>どうだ,耳が痛かろう(笑) これが2003年に(原書が)出版された本の内容だよ。</p>
<p>Twitter でも書いたが,人の靭性を軽視すると,いったん破られたときに止める手段がなくなり class break を引き起こしやすい。
かといって人に依存しすぎて「運用でカバー」でも人が疲弊するだけだけど。
お互いが有機的に連携できる落とし所を探すのが「改善」というやつである。</p>
<h2>ブックマーク</h2>
<ul>
<li><a href="https://text.baldanders.info/remark/2020/09/nist-sp-800-207-zero-trust-architecture/">NIST SP 800-207: “Zero Trust Architecture”</a></li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/4822283100?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51-pZ52JsUL._SL160_.jpg" width="107" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/4822283100?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">セキュリティはなぜやぶられたのか</a></dt>
<dd>ブルース・シュナイアー (著), 井口 耕二 (翻訳)</dd>
<dd>日経BP 2007-02-15</dd>
<dd>単行本</dd>
<dd>4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (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">原書のタイトルが “<a href="https://www.amazon.co.jp/dp/B000PY3NB4?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">Beyond Fear: Thinking Sensibly About Security in an Uncertain World</a>” なのに対して日本語タイトルがどうしようもなくヘボいが中身は名著。とりあえず読んどきなはれ。ゼロ年代当時 9.11 およびその後の米国のセキュリティ政策と深く関連している内容なので,そのへんを加味して読むとよい。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2019-02-11">2019-02-11</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/B07ND6QTN4?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51NHngUGOFL._SL160_.jpg" width="103" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B07ND6QTN4?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">OODA LOOP(ウーダループ)―次世代の最強組織に進化する意思決定スキル</a></dt>
<dd>チェット リチャーズ (著), 原田 勉 (翻訳)</dd>
<dd>東洋経済新報社 2019-02-22 (Release 2019-02-22)</dd>
<dd>Kindle版</dd>
<dd>B07ND6QTN4 (ASIN)</dd>
</dl>
<p class="description">買ったはいいが,実はまだ読んでない。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2019-07-02">2019-07-02</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- OODA LOOP -->
NIST SP 800-207: “Zero Trust Architecture”
tag:text.Baldanders.info,2020-09-17:/remark/2020/09/nist-sp-800-207-zero-trust-architecture/
2020-09-17T03:25:07+00:00
2020-12-27T01:17:35+00:00
Refactoring することを前提としたシステム設計が大事。
Spiegel
https://baldanders.info/profile/
<p>毎度の言い訳だが(笑),私がネットワーク管理者でセキュリティ管理者だったのは遥か昔の牧歌的な時代であり,現在時点で参加・所属する企業・組織のポリシーについてどうこう言う権限はないし,その気もない。
ただし,自衛のための知識を摂取し続けることは必要だと思っている。</p>
<p>というわけで,今回は2020年8月に最終版が公開された NIST <a href="https://csrc.nist.gov/publications/detail/sp/800-207/final" title="SP 800-207, Zero Trust Architecture | CSRC">SP 800-207</a> の触りの部分を覚え書きとして記しておく。</p>
<ul>
<li><a href="https://csrc.nist.gov/publications/detail/sp/800-207/final" title="SP 800-207, Zero Trust Architecture | CSRC">SP 800-207, Zero Trust Architecture | CSRC</a></li>
<li><a href="https://www.pwc.com/jp/ja/knowledge/column/awareness-cyber-security/zero-trust-architecture-jp.html">NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳 | PwC Japanグループ</a></li>
</ul>
<h2>Zero Trust および Zero Trust Architecture の定義</h2>
<p><a href="https://csrc.nist.gov/publications/detail/sp/800-207/final" title="SP 800-207, Zero Trust Architecture | CSRC">SP 800-207</a> では Zero Trust および Zero Trust Architecture は以下のように定義づけられている。</p>
<figure lang="en">
<blockquote><q><i>Zero trust</i> (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. <i>Zero trust architecture</i> (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero trust enterpriseis the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan</q>.</blockquote>
<figcaption><div>via <q><a href="https://csrc.nist.gov/publications/detail/sp/800-207/final">SP 800-207: Zero Trust Architecture</a></q></div></figcaption>
</figure>
<p>ポイントは,アクセスを行うリソース,権限,期間が最小となるよう設計することだ。
これは,特定の安全地帯に入る許可さえあれば,内部のリソースにラフにアクセスできる従来の境界型セキュリティ設計とは大きく異なっている。</p>
<p>ちなみに <a href="https://csrc.nist.gov/publications/detail/sp/800-207/final" title="SP 800-207, Zero Trust Architecture | CSRC">SP 800-207</a> では,アクセスする対象を <q lang="en">resource</q> と呼んでいる。
これは単なるデータだけではなく物理的なデバイスも対象となっていることを示す。
つまり (<a href="https://www.gartner.com/jp/newsroom/press-releases/pr-20200910" title="ガートナー、「日本における未来志向型インフラ・テクノロジのハイプ・サイクル:2020年」を発表">日本では既に幻滅期に入っている</a>) IoT も視野に入っているわけだ。</p>
<p>さらに <a href="https://csrc.nist.gov/publications/detail/sp/800-207/final" title="SP 800-207, Zero Trust Architecture | CSRC">SP 800-207</a> では,アクセスを行う主体を <q lang="en">subjects</q> と呼んでいる。
そう呼ぶからには subjects が指すのは人間(ユーザ)だけではなく,アプリケーション,サービス,デバイス等も含まれる。
また subjects は <q lang="en">authorized and approved subjects</q> と <q lang="en">all other subjects</q> で色分けされている。
もちろん <q lang="en">all other subjects</q> の代表は「攻撃者(attackers)」である。</p>
<p>つまり,あるリソースに対して認証・承認されない actor は,システム上の役割に関わらず,<strong>全て敵</strong>である(笑) この辺が「ゼロトラスト」と呼ばれる所以なのだろう。</p>
<p>ZT/ZTA が重視される理由としては以下の2つが挙げられると思う。</p>
<ol>
<li>企業・組織への攻撃が巧妙化していて,セキュリティ管理の比重が防御から監視へシフトした</li>
<li>クラウド上の XaaS リソースは「境界型」では管理できない</li>
</ol>
<p>できれば安直にクラウドに繋がろうとするスマート家電もなんとかしてほしいのだが…</p>
<h2>Zero Trust Architecture の基本理念</h2>
<p><a href="https://csrc.nist.gov/publications/detail/sp/800-207/final" title="SP 800-207, Zero Trust Architecture | CSRC">SP 800-207</a> では ZTA の基本理念として,以下の7つの項目を挙げている。</p>
<figure lang="en">
<blockquote><ol>
<li>All data sources and computing services are considered resources.</li>
<li>All communication is secured regardless of network location.</li>
<li>Access to individual enterprise resources is granted on a per-session basis.</li>
<li>Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes.</li>
<li>The enterprise monitors and measures the integrity and security posture of all owned and associated assets.</li>
<li>All resource authentication and authorization are dynamic and strictly enforced before access is allowed.</li>
<li>The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.</li>
</ol>
</blockquote>
<figcaption><div>via <q><a href="https://csrc.nist.gov/publications/detail/sp/800-207/final">SP 800-207: Zero Trust Architecture</a></q></div></figcaption>
</figure>
<p>ちなみに日本語訳は以下の通り。</p>
<figure>
<blockquote><ol>
<li>すべてのデータソースとコンピューティングサービスをリソースとみなす</li>
<li>ネットワークの場所に関係なく、すべての通信を保護する</li>
<li>企業リソースへのアクセスは、セッション単位で付与する</li>
<li>リソースへのアクセスは、クライアントアイデンティティ、アプリケーション/サービス、リクエストする資産の状態、その他の行動属性や環境属性を含めた動的ポリシーにより決定する</li>
<li>すべての資産の整合性とセキュリティ動作を監視し、測定する</li>
<li>すべてのリソースの認証と認可を動的に行い、アクセスが許可される前に厳格に実施する</li>
<li>資産、ネットワークインフラストラクチャ、通信の現状について可能な限り多くの情報を収集し、セキュリティ態勢の改善に利用する</li>
</ol>
</blockquote>
<figcaption><div><q><a href="https://www.pwc.com/jp/ja/knowledge/column/awareness-cyber-security/zero-trust-architecture-jp.html">NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳 | PwC Japanグループ</a></q>より</div></figcaption>
</figure>
<p>面白いのは ZTA に最初から「監視」が組み込まれていること,常に状況をフィードバックして「改善」のサイクルを構築するところまでがセットになっていることだろう。</p>
<p>セキュリティに於いても PDCA サイクル,いや今なら OODA ループか,が重要ということやね(笑)</p>
<h2>大変なのは…</h2>
<p>ZT を組み込むこと自体は,そう難しくないだろう。
おそらくは既存のシステムに ZT の仕組みをラッピングすることで構成可能なはずだ。</p>
<figure lang="en">
<blockquote class="nobox" style='margin:0 auto;text-align:center;'>
<a href="https://csrc.nist.gov/publications/detail/sp/800-207/final"><img src="./zero-trust-access.png" srcset="./zero-trust-access.png 1183w" sizes="(min-width:600px) 500px, 80vw" alt="SP 800-207: Zero Trust Architecture" loading="lazy"></a>
</blockquote>
<figcaption><div>via <q><a href="https://csrc.nist.gov/publications/detail/sp/800-207/final">SP 800-207: Zero Trust Architecture</a></q></div></figcaption>
</figure>
<p>大変なのは ZTA におけるリソースとサブジェクト(の権限)の定義・運用・評価だろう。
これ,かなり細かい要求分析が必要だと思うよ。</p>
<p>当然ながら人間組織の役職で権限を決めるわけにはいかない。
システム管理者やセキュリティ管理者(セキュリティ企業も含めて)であっても「アクセスしてはいけないリソース」はある。
サブジェクトやリソースの杜撰な管理で <a href="https://text.baldanders.info/remark/2020/07/class-breaks-from-twitter/" title="Twitter から始まる Class Break">Class Break を引き起こした Twitter</a> の事例は耳に新しいだろう。
日本での最近の Class Break 事例は「ドコモロ系事案<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup>」か(笑)</p>
<p>だからこそループを回して「改善」していかなければならないんだろうけど。
Refactoring することを前提としたシステム設計が大事。</p>
<h2>ブックマーク</h2>
<ul>
<li><a href="https://github.blog/2020-09-24-lightning-qa-devsecops-in-five-with-maya-kaczorowski/">Lightning Q&A: DevSecOps in five with Maya Kaczorowski - The GitHub Blog</a></li>
<li><a href="https://www.atmarkit.co.jp/ait/articles/2009/15/news007.html">NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係:働き方改革時代の「ゼロトラスト」セキュリティ(6) - @IT</a></li>
<li><a href="https://jpn.nec.com/cybersecurity/blog/201016/index.html">【超図解】ゼロトラスト: NECセキュリティブログ | NEC</a></li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/4822283100?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51-pZ52JsUL._SL160_.jpg" width="107" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/4822283100?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">セキュリティはなぜやぶられたのか</a></dt>
<dd>ブルース・シュナイアー (著), 井口 耕二 (翻訳)</dd>
<dd>日経BP 2007-02-15</dd>
<dd>単行本</dd>
<dd>4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (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">原書のタイトルが “<a href="https://www.amazon.co.jp/dp/B000PY3NB4?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">Beyond Fear: Thinking Sensibly About Security in an Uncertain World</a>” なのに対して日本語タイトルがどうしようもなくヘボいが中身は名著。とりあえず読んどきなはれ。ゼロ年代当時 9.11 およびその後の米国のセキュリティ政策と深く関連している内容なので,そのへんを加味して読むとよい。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2019-02-11">2019-02-11</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/4757143044?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/413qoSjODUL._SL160_.jpg" width="108" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/4757143044?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">信頼と裏切りの社会</a></dt>
<dd>ブルース・シュナイアー (著), 山形 浩生 (翻訳)</dd>
<dd>NTT出版 2013-12-24</dd>
<dd>単行本(ソフトカバー)</dd>
<dd>4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (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">社会における「信頼」とは。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-11-28">2015-11-28</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/B07ND6QTN4?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51NHngUGOFL._SL160_.jpg" width="103" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B07ND6QTN4?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">OODA LOOP(ウーダループ)―次世代の最強組織に進化する意思決定スキル</a></dt>
<dd>チェット リチャーズ (著), 原田 勉 (翻訳)</dd>
<dd>東洋経済新報社 2019-02-22 (Release 2019-02-22)</dd>
<dd>Kindle版</dd>
<dd>B07ND6QTN4 (ASIN)</dd>
</dl>
<p class="description">買ったはいいが,実はまだ読んでない。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2019-07-02">2019-07-02</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- OODA LOOP -->
<div class="footnotes" role="doc-endnotes">
<hr>
<ol>
<li id="fn:1">
<p><a href="https://piyolog.hatenadiary.jp/entry/2020/09/16/064653" title="不正利用が発生した電子決済サービスについてまとめてみた - piyolog">キャッシュレス決済を使った不正利用に関する一連のインシデント</a>のこと。 Facebook の TL で見かけた「ドコモロ系事案」のフレーズが面白かったので使ってみた(笑) <a href="#fnref:1" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
</ol>
</div>
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>
“Blockchain and Trust” by Bruce Schneier
tag:text.Baldanders.info,2019-02-13:/remark/2019/02/blockchain-and-trust-by-bruce-schneier/
2019-02-13T13:56:46+00:00
2020-01-05T11:59:50+00:00
久しぶりで抜群に面白い記事を見た。こういうとき英語不得手なのが本当に不便だよ。
Spiegel
https://baldanders.info/profile/
<p>久しぶりで抜群に面白い記事を見た。</p>
<ul>
<li><a href="https://www.schneier.com/blog/archives/2019/02/blockchain_and_.html">Blockchain and Trust - Schneier on Security</a></li>
</ul>
<p>これは元々 <a href="https://www.wired.com/story/theres-no-good-reason-to-trust-blockchain-technology/" title="There's No Good Reason to Trust Blockchain Technology | WIRED">WIRED に掲載された記事</a>らしい。</p>
<p>なんで WIRED.jp はこの記事の翻訳を出さないのだろう。
まぁ,いいや。</p>
<div class="box"><p>【追記 2019-02-26】非公式だが翻訳記事を公開されている方がおられた。感謝。</p>
<ul>
<li><a href="https://okuranagaimo.blogspot.com/2019/02/blog-post_14.html">ブログ: ブロックチェーンと信頼</a></li>
</ul></div>
<p>この記事に関連する記事もいくつか紹介されている。</p>
<ul>
<li><a href="https://blockonomi.com/bruce-schneiers-slams-blockchain/">Bruce Schneier’s Wired Op-Ed Slams Blockchain, But Why? - Blockonomi</a></li>
<li><a href="https://breakermag.com/bruce-schneier-is-right-about-blockchains-biggest-flaw-and-completely-wrong-about-its-longterm-significance/">Bruce Schneier Is Right About Blockchain’s Biggest Flaw—and Completely Wrong About Its Long-term Significance</a></li>
<li><a href="https://queue.acm.org/detail.cfm?id=3305265">A Hitchhiker’s Guide to the Blockchain Universe - ACM Queue</a></li>
<li><a href="https://arstechnica.com/information-technology/2019/02/researcher-counts-the-reasons-he-wants-cryptocurrency-burned-with-fire/">Fire (and lots of it): Berkeley researcher on the only way to fix cryptocurrency | Ars Technica</a></li>
</ul>
<figure style='margin:0 auto;text-align:center;'>
<div style="position: relative; margin: 0 2rem; padding-bottom: 56.25%; padding-top: 30px; height: 0; overflow: hidden;">
<iframe class="youtube-player" style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" allowfullscreen frameborder="0" src="https://www.youtube-nocookie.com/embed/xCHab0dNnj4" allowfullscreen></iframe>
</div>
<figcaption><div><a href="https://www.youtube.com/watch?v=xCHab0dNnj4">Blockchains and Cryptocurrencies: Burn It With Fire (Nicholas Weaver) - YouTube</a></div></figcaption>
</figure>
<figure lang="en">
<blockquote>
<q>I have wanted to write this essay for over a year. The impetus to finally do it came from an invite to speak at the <a href="https://hgf18.sched.com/speaker/bruce_schneier.1ypp0elm">Hyperledger Global Forum</a> in December. This essay is a version of the talk I wrote for that event, made more accessible to a general audience.</q>
</blockquote>
<figcaption><div>via <q><a href="https://www.schneier.com/blog/archives/2019/02/blockchain_and_.html">Blockchain and Trust</a></q></div></figcaption>
</figure>
<p>この週末を使ってゆっくり読むか。</p>
<p>どなたか翻訳してくれないかなぁ。
こういうとき英語不得手なのが本当に不便だよ。
若い方たち,英語はしっかり習得するんだよ。
日本語なんて辺境な言語に引き篭もってると世界から取り残されるぞ。</p>
<h2>ブックマーク</h2>
<ul>
<li><a href="https://japan.zdnet.com/article/35132483/">解説「ゼロトラスト」シフト–“境界”セキュリティの誕生と限界までの道のり - ZDNet Japan</a></li>
<li><a href="https://yamdas.hatenablog.com/entry/20190224/blockchainandtrust">ブルース・シュナイアーが「ブロックチェーンと信頼」について語る - YAMDAS現更新履歴</a></li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/4757143044?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/413qoSjODUL._SL160_.jpg" width="108" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/4757143044?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">信頼と裏切りの社会</a></dt>
<dd>ブルース・シュナイアー (著), 山形 浩生 (翻訳)</dd>
<dd>NTT出版 2013-12-24</dd>
<dd>単行本(ソフトカバー)</dd>
<dd>4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (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">社会における「信頼」とは。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-11-28">2015-11-28</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</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>
『暗号技術入門 第3版』をななめ読み
tag:text.Baldanders.info,2015-09-20:/remark/2015/cryptography-introduction/
2015-09-20T12:43:17+00:00
2020-01-05T11:59:50+00:00
今回は大幅改訂版なので,以前のを持ってる人も買っておいて損はない。
Spiegel
https://baldanders.info/profile/
<p>結城浩さんの『<a href="http://www.hyuki.com/cr/">暗号技術入門 第3版</a>』がついに登場。
前の第2版のときは細々した追記が主だったような気がするが,今回は大幅改訂版なので,以前のを持ってる人も買っておいて損はない。
主な改訂内容としては</p>
<ul>
<li>SHA-3 について詳しく解説</li>
<li>HeartBleed や POODLE など,最近の攻撃手法について言及</li>
<li>付録で楕円曲線暗号(Elliptic Curve Cryptography)について詳しく解説</li>
<li>Bitcoin というか Bitcoin の中の重要な技術要素である Block Chain について詳しく解説</li>
</ul>
<p>他にも <a href="https://www.gnupg.org/">GnuPG</a> の記述が modern version に対応してたり,認証つき暗号(AEAD; Authenticated Encryption with Associated Data)およびその実装である GCM (Galois/Counter Mode) への言及があったり,いろいろ細かく手直しされている。</p>
<p>特に楕円曲線暗号の解説は秀逸で,入門レベルでの解説の中では一番分かりやすかった。
あと Block Chain の解説もお勧め。
Bitcoin や Block Chain に関する解説本はすでにたくさん出ているが,暗号技術の観点からきちんと解説しているものは少なく,「信用モデル」にまで話を展開しているものは更に少ない。</p>
<p>結局,暗号システムの実装というのは究極的には「信用モデル」の開発であると言える。
問題は「信用モデル」はロジックだけでは成立しない,ということだ。
『<a href="http://www.hyuki.com/cr/">暗号技術入門 第3版</a>』では信用モデルの例として hierarchical PKI の典型である X.509 と OpenPGP の Web of Trust,そして Block Chain を挙げているが,それぞれ特徴があって比較すると面白い。
たとえば Block Chain はユーザ間に働く経済的 incentive を巧妙に使うが,それだけにパラメータの調整が難しいし, Mt. Gox のような経済リスクも考慮しなくてはならない。</p>
<p>そもそも信用というのは過去の事実に対してのみ評価可能なのに,実際に評価したいのは現在及び未来についてなのだ。
これって本来は不能解だよね。
でも信用が評価できなくては世の中は回らない。
だから,どうにかして実用可能なレベルにまで近似できないか,と専門家やエンジニアは頭を悩ますわけ。</p>
<p>そういったことを頭の隅に入れながら読めば,この本は単なるリファレンス本ではないことに気づくと思う。</p>
<p>最後にちょっとだけ注文をつけるなら「前方秘匿性(PFS; Perfect Forward Secrecy)」および OTR (Off-the-Record) Messaging の肝である「否認可能(Deniability)」についても言及が欲しかった<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup>。
メッセージングの世界においてはこのふたつが重要な要件になってきているからだ。</p>
<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/4757143044?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/413qoSjODUL._SL160_.jpg" width="108" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/4757143044?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">信頼と裏切りの社会</a></dt>
<dd>ブルース・シュナイアー (著), 山形 浩生 (翻訳)</dd>
<dd>NTT出版 2013-12-24</dd>
<dd>単行本(ソフトカバー)</dd>
<dd>4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (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">社会における「信頼」とは。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-11-28">2015-11-28</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>PFS についてはもしかしたら見落としてるかもしれないが。なにせ斜め読みだったから。 <a href="#fnref:1" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
</ol>
</div>