List of X509 [text.Baldanders.info]

「仮想通貨」と公開鍵基盤

2018-02-05T10:10:06+00:00

Twitter で見かけた記事。

Satoshiが注意深く設定した世界の境界線 – Shin’ichiro Matsuo – Medium

Satoshi Nakamoto 氏の論文を引いていてかなり面白い内容だと思うが，言いたいことは単純で，私がこれまで述べてきた通り

Bitcoin のアドレスの帰属先について Bitcoin/Blockchain は関知しない。Bitcoin が気にするのは Blockchain に記載されるアドレスの一貫性と無矛盾性である。アドレスの証明が必要な場合は外部の PKI を利用するか新たに組み込む必要がある

ということに尽きる。

今回はこの部分についてもう少し詳しく書いてみる。

まずは定義から

Blockchain もしくは Blockchain に準ずる技術を用い，価値可換なトークンによって取引を行うシステムを括弧書きで「仮想通貨」または「「仮想通貨」システム」と命名する。この時の「価値可換なトークン」を「コイン」と命名する。コインは量で表すことができるものとする。

また「仮想通貨」システムで発生する取引を記録する追記型データベースを「元帳」と命名する。もちろん元帳は「Blockchain もしくは Blockchain に準ずる技術」を用いて実装されているわけだ。

ここで，ある「仮想通貨」システム上でユーザ $A$ からユーザ $B$ へコインを移転¹ する「取引」を考える。

「ある「仮想通貨」システム」を $COIN$ とする
取引を $T$ とし，取引の際に移転するコインの量を $c$ とする
$A$ が持つ「仮想通貨」のアドレスを $a$ とし， $B$ が持つ「仮想通貨」のアドレスを $b$ とする

このときの取引全体を示す図式² を以下のように記述してみる。

\[ COIN : A[a] \xrightarrow{T(c)} B[b] \]

このとき取引 $T$ を元帳に追記する内容は

\[ a \xrightarrow{c} b \]

であり，取引関係者である $A$ や $B$ は一切登場しないのがポイントである。

「仮想通貨」はアドレスの帰属先を証明（Certificate）しない

「仮想通貨」は $a$ の帰属先が $A$ であること，あるいは $b$ の帰属先が $B$ であることを証明しないし証明できない。もう少し厳密にいうなら「「仮想通貨」はアドレスの帰属先を証明する責務を負わない」と言える。

このことが何をもたらすか，いくつかシナリオを考えてみよう。

$a$ の帰属先が $A$ であると証明できない
- $B$ は入金 $c$ を $A$ によるものではないと主張できる。 $B$ は $A$ からの入金を否認し $A$ に尚も $c$ を請求するかもしれない
- $a$ は別の誰か（たとえば $E$）に乗っ取られているかもしれない。これにより $B$ は取引不成立とみなし $A$ に何らかのペナルティを課すかもしれない \[ COIN : E[a] \xrightarrow{T( c )} B[b] \]
$b$ の帰属先が $B$ であると証明できない
- $B$ は $b$ が自身に帰属しないと主張できる。これにより $B$ は $A$ からの入金を否認できる
- $b$ は別の誰かに乗っ取られているかもしれない。これにより $A$ は取引不成立とみなして出金を拒否した上で $B$ に何らかのペナルティを課すかもしれない（出金した $c$ を上回る量の賠償請求を行うなど） \[ COIN : A[a] \xrightarrow{T( c )} E[b] \]

Coincheck 事例の事実関係は（今のところ）よく分かってない部分もあるが，知らない誰かがアドレスを乗っ取って知らない誰かへ「流出」したということであれば

\[ COIN : E[a] \xrightarrow{T(c)} E[b] \]

という図式も成り立つ。

しかし実態がどのようなものであれ「仮想通貨」の元帳には $a \xrightarrow{c} b$ という記録が事実として残るのみで，それが望んだ取引なのか何らかの不正を含んでいるのかといった点について「仮想通貨」は一切関知しない。

「仮想通貨」は P2P を前提とする

アドレスの帰属先を証明できないというのは実際の取引において致命的な問題となるが，それでもそれなりにまわっているのは「仮想通貨」がユーザ同士の P2P (peer-to-peer) な関係を前提にしているからである。つまり「$a$ の帰属先は $A$ である」であり「$b$ の帰属先は $B$ である」であることを $A,B$ 相互に「信用」していることが取引の前提になっている。

しかし，見知った者同士の取引ならともかく，不特定の誰かを何の担保もなく「信用」するのは無理だし，その「信用」そのものを数学的に示す方法は存在しない。存在しないのであれば，それに代わる「運用でカバー」するしかない。

この「運用」のロジックのことを「信用モデル（trust model）」と呼ぶ。「仮想通貨」自体はアドレスに対する信用モデルを持たないが，「仮想通貨」を利用するサービスが何らかの信用モデルと組み合わせることによりアドレスの帰属先を証明することが可能になる。また，出来のよい信用モデルを導入することにより不正取引を働くインセンティブが低下することも期待できるだろう。

おそらく「仮想通貨」を利用するユーザの多くはウォレット・サービスや通貨交換所が信用モデルを組み込むことを期待しているんじゃないかと思うが（投機目的で「仮想通貨」を運用している人はどうでもいいと思ってるかも知れない），実際にそれらのサービスがアドレスをどうやって「運用」してるのかは（私は現在の「仮想通貨」への興味が薄いので）知らない。

公開鍵基盤の信用モデル

ここで少し目先を変えて公開鍵基盤（Public Key Infrastructure; PKI）の信用モデルを2つほど紹介してみる。公開鍵基盤というのは公開鍵が誰に帰属するかをサービスを横断して証明するための技術基盤である。

なぜ公開鍵基盤かというと，公開鍵を使った暗号通信の要件が「仮想通貨」による取引の要件によく似ていると考えられるからだ。公開鍵を使った暗号通信には以下の4つの要件がある。

機密性（Confidentiality）
完全性（Integrity）
認証（Authentication）
否認防止（Non-repudiation）

暗号なので1番目は言わずもがなだが，2番目は電子署名によって達成できる。そして3番目を達成する手段として公開鍵基盤がある。

ちなみに2番目と3番目が達成できれば4番目も達成可能なのだが，否認防止の重要性は前節までを見ればお分かりいただけるだろう。

X.509 の信用モデル

典型的な hierarchical PKI として有名なのが X.509 である。 Web の HTTPS 通信で必要な「電子証明書」は X.509 下で運用されている。

X.509 では認証局（Certification Authority; CA）が公開鍵（の帰属先）を証明する電子証明書を発行する。電子証明書は具体的には，ユーザの公開鍵に対して認証局の鍵で電子署名を付与したものである。では，認証局の鍵はどうやって証明するかというと，さらに上位の認証局が証明する。ただし最上位のルート認証局は誰も証明してくれない（自己証明のみ）。

graph TD CA1["root CA"]-- Digital Sign -->CA2 CA1-- Digital Sign -->CA3 CA2-- Digital Sign -->Aa(("A[a]")) CA3-- Digital Sign -->Bb(("B[b]"))

X.509 は「認証局は信用できる」という前提に立った信用モデルと言える。言い方を変えると，ある認証局が信用できるのであれば配下の認証局やユーザは総て信用できる。

X.509 は大規模かつ安定的な運用に向いているが，いったん認証局の信用が崩れると配下の認証局やユーザの信用が一気に崩れることになる。そのため，認証局，特にルート認証局では高いセキュリティが要求される。

OpenPGP の信用モデル

OpenPGP における典型的な信用モデルは「信用の輪（web of trust）」と呼ばれている³。信用の輪はユーザ間の P2P な関係がベースになっている。

信用の輪ではユーザ同士がお互いの公開鍵に電子署名を付与する。たとえば $A$ と $B$ に面識があるなら，相互に電子署名を付与することができる。

graph LR Aa(("A[a]")) Bb(("B[b]")) Aa-- Digital Sign -->Bb Bb-- Digital Sign -->Aa

ここで3人目の $D$ に登場してもらおう。 $B$ と $D$ は面識があって電子署名を交わしているが， $A$ と $D$ は面識がないものとする。

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

この場合でも $A$ と $B$ との関係， $B$ と $D$ との関係をもとに $A$ から見て $D$ も信用できるとみなすのだ。

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

信用の輪はコミュニティ内のアドホックな鍵管理に向いているが，全く関係のない第3者を証明するのは難しい。

X.509 と OpenPGP

山根信二さん等の「OpenPGPとPKI 」では X.509 と OpenPGP の PKI の比較を行っている⁴。以下に比較表を示す。

特徴	X.509	OpenPGP
PKI の形態	hierarchical PKI	trust-file PKI
公開鍵の認証者	専門機関（CA）	各ユーザ
信頼点	ルート CA	利用者自身（面識）
認証の連鎖構造	ツリー型	ユーザ中心型
認証者を認証する根拠	利用者による選択	利用者自身
証明書の破棄と管理	あり	不完全
コスト	高い	低い

X.509 と OpenPGP の信用モデルはコンセプトが直交しているためどちらが正解とは言えない。また相互補完的に運用することも可能である。

「仮想通貨」の信用モデルは？

「仮想通貨」のアドレスの運用についても，おそらく正解はひとつではなく，さまざまな信用モデルがありうると思う。また信用モデルを「仮想通貨」システム自体に埋め込むのか周辺の（ウォレットや交換所などの）サービスで提供するのかというのも議論の余地があると思う。

「仮想通貨」が単なる投機物件ではなく generative な経済活動の技術基盤として生き残っていくことを期待したい。

ブックマーク

OpenPGP 鍵管理に関する考察

参考図書

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

UNDERGROUND MARKET　ヒステリアン・ケース: 藤井太洋 (著); 朝日新聞出版 2013-11-07 (Release 2013-10-25); Kindle版; B00FONW2V8 (ASIN); 評価

[Comment] 日本で「仮想通貨」が流行る前に登場した傑作。つかエンジニアは全員「UNDERGROUND MARKET」シリーズを読め！

reviewed by Spiegel on 2016-01-07 (powered by PA-APIv5)

$A$ から見ると $B$ への「出金」， $B$ からみると $A$ からの「入金」と言える。 ↩︎
数式じゃなくて図式。数式記号を使ってるけどあくまで図式と言い張ってみる。 ↩︎
OpenPGP の実装である GnuPG では信用の輪以外にも TOFU (Trust On First Use) などの信用モデルを実装している（参考： “TOFU for OpenPGP ”）。 ↩︎
この論文は2002年に旧 OpenPKSD.org で公開されたが，サイトそのものが消失したため Internet Archive からサルベージした。 ↩︎

HTTPS 通信監視機器のリスク

2017-03-21T11:32:28+00:00

2015年の CERT/CC ブログ記事 “The Risks of SSL Inspection” に関する注意喚起が今更ながら出ている。

The Risks of SSL Inspection

「HTTPS 通信監視機器」というのは，ぶっちゃけていうと， HTTPS 暗号通信¹ に「中間者攻撃（man-in-the-middle attack）」を仕掛けて通信を傍受し malware 等を検出・排除する「セキュリティ製品」である。

HTTPS 通信監視機器のいくつかにはセキュリティ上の問題が存在する。 “The Risks of SSL Inspection” から抜き出してみよう。

Incomplete validation of upstream certificate validity
Not conveying validation of upstream certificate to the client
Overloading of certificate Canonical Name (CN) field
Use of the application layer to convey certificate validity
Use of a User-Agent HTTP header to determine when to validate a certificate
Communication before warning
Same root CA certificate

これらの問題があると推測される製品のリストが “The Risks of SSL Inspection” に挙がっているので該当者は確認してみるとよいだろう。また以下のサイトからも確認できる。

badssl.com

“The Risks of SSL Inspection” では以下のように結論付けている。

SSL and TLS do not provide the level of end-to-end security that users may expect. Even in absence of SSL inspection, there are problems with how well browsers are conveying SSL information to users. The fact that "SSL inspection" is a phrase that exists, should be a blazing red flag that what you think SSL is doing for you is fundamentally broken.

via The Risks of SSL Inspection

以前も書いたが，HTTPS 通信監視機器（あるいは HTTPS Deep Inspection）の存在自体がインターネットの “End to End” 原則を崩すものであり，ひいては「ネットの中立性」に楔を入れるものである。しかし「馬も鹿も暗号化する時代」にこの原則は風前の灯である。たとえば CMS の面倒すらろくすっぽ見られないユーザが「うちも Let’s la Encrypt」とか言い出して脆弱性だらけのサイトを暗号化したらどうなるのか。

ネットワーク・セキュリティ専門家から企業あるいは私たち個人に至るまで，場当たりな対処に満足するのではなく，この「現実」にきちんと向き合うべきだと思うのだが，どうだろう。

【おまけの追記】公開鍵基盤が担保するもの

他の事象だが同じ公開鍵基盤（Public Key Infrastructure; PKI）に関連している事柄なので，おまけの追記ということで。

「Symantecが再びGoogleの信頼を失った件についてのメモ」にもあるように Symantec （傘下の Thawte）は既に前科持ちなので「またか（sigh）」って感じなのだが…

X.509 型の公開鍵基盤は認証局（Certification Authority; CA）が信頼できることが絶対条件で，これが崩れると機能しなくなる。

喩えるならお金と銀行の関係と似ている。銀行はお金の価値を担保するが銀行が信用できないのならお金の価値を担保するものがなくなる。同じく認証局が管理する証明書は認証局が安全性を担保できているからこそ意味がある。そうでなければオレオレ証明書またはそれ以下の価値しかない。

この問題は Symantec と Google の2者間の喧嘩だと思ったら物事を見誤る。現在 Web を支配している公開鍵基盤の根幹に関わる問題なのである。

それにしても，昔「EV SSL は『屋上屋を架す』ようにしか見えない」と書いたが，まったくもってその通りだったな（笑）

ブックマーク

参考図書

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

念のため簡単に説明しておくと， HTTPS (Hypertext Transfer Protocol Secure) 暗号通信は WWW (World Wide Web) におけるクライアント-サーバ間の通信経路を暗号化する仕組みである。具体的には TLS (Transport Layer Security) 等のプロトコルを用い公開鍵暗号方式を使ってセッション鍵を生成する。また公開鍵暗号方式の公開鍵は X.509 方式の公開鍵基盤によって管理される。 ↩︎

OpenPGP に関する話題

2017-03-05T08:19:39+00:00

さてさて。 2月も逃げちゃいましたよ。

GnuPG 2.1.19 がリリース

[Announce] GnuPG 2.1.19 released

セキュリティアップデートはなし。主な修正・変更点は以下の通り。

gpg: Print a warning if Tor mode is requested but the Tor daemon is not running.
gpg: New status code DECRYPTION_KEY to print the actual private key used for decryption.
gpgv: New options --log-file and --debug.
gpg-agent: Revamp the prompts to ask for card PINs.
scd: Support for multiple card readers.
scd: Removed option --debug-disable-ticker. Ticker is used only when it is required to watch removal of device/card.
scd: Improved detection of card inserting and removal.
dirmngr: New option --disable-ipv4.
dirmngr: New option --no-use-tor to explicitly disable the use of Tor.
dirmngr: The option --allow-version-check is now required even if the option --use-tor is also used.
dirmngr: Handle a missing nsswitch.conf gracefully.
dirmngr: Avoid PTR lookups for keyserver pools. The are only done for the debug command “keyserver --hosttable”.
dirmngr: Rework the internal certificate cache to support classes of certificates. Load system provided certificates on startup. Add options --tls, --no-crl, and --systrust to the “VALIDATE” command.
dirmngr: Add support for the ntbtls library.
wks: Create mails with a “WKS-Phase” header. Fix detection of Draft-2 mode.
The Windows installer is now build with limited TLS support.
Many other bug fixes and new regression tests.

$ gpg --version
gpg (GnuPG) 2.1.19
libgcrypt 1.7.6
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ********
サポートしているアルゴリズム:
公開鍵: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
暗号方式: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
    CAMELLIA128, CAMELLIA192, CAMELLIA256
ハッシュ: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
圧縮: 無圧縮, ZIP, ZLIB, BZIP2

映像の証明

Guardian Project が提供している CameraV というカメラアプリがあるが，この中の Proof Mode という機能を有効にすることで写した写真やビデオの「証明」を作成することができるらしい。

On the technical front, what the app is doing is automatically generating an OpenPGP key for this installed instance of the app itself, and using that to automatically sign all photos and videos at time of capture. A sha256 hash is also generated, and combined with a snapshot of all available device sensor data, such as GPS location, wifi and mobile networks, altitude, device language, hardware type, and more. This is also signed, and stored with the media. All of this happens with no noticeable impact on battery life or performance, every time the user takes a photo or video.

via Combating “Fake News” With a Smartphone “Proof Mode”

まぁ，いまどき映像であってもいくらでも捏造できるからねぇ。こういう仕組みも必要になってくるというわけだ。 Proof Mode の設計目標は以下の通り。

Run all of the time in the background without noticeable battery, storage or network impact
Provide a no-setup-required, automatic new user experience that works without requiring training
Use strong cryptography for strong identity and verification features, but not encryption
Produce “proof” sensor data formats that can be easily parse, imported by existing tools (CSV)
Do not modify the original media files; all proof metadata storied in separate file
Support chain of custody needs through automatic creation of sha256 hashes and PGP signatures
Do not require a persistent identity or account generation

内部では映像毎に OpenPGP 電子署名を作成するが，鍵の生成や運用は自動でやってくれるようだ。便利。なのだが，イマイチ使い勝手がよく分からない。使い方はおいおい覚えていくとしよう。

ちなみに CameraV では撮った映像を暗号化したり panic 時に映像を全部消去できたりする機能もあるらしい。最近いろいろ物騒だからねぇ。

電子メールの暗号化

ここのところ暗号化電子メールの話題をよく見かける。

「グーグルのメール暗号化Chromeアプリケーション「E2EMail」がオープンソースに」の最後の方に出てくる Key Transparency については以前に本家サイトで紹介したので参考にどうぞ。

Google による OpenPGP 鍵配送の解決提案 — Baldanders.info

個人的には（OpenPGP ではないが）「Android版Gmail v7.2でS/MIMEの暗号化機能をサポート」のほうに注目している。 S/MIME は X.509 型の PKI で鍵を運用するもので Web メールやケータイアプリでの鍵管理がやりやすいのが特徴。こちらは暗号化より電子署名によるメールの証明がやりやすくなるのではないだろうか。

企業からのプロモーションメールを S/MIME 形式で電子署名することによって HTTPS の EV SSL と同様な効果が狙えると思う。 S/MIME 形式で電子署名が一般的になれば spam メールの排除もやりやすくなるかもしれない。

電子署名ではなく暗号化メールでいうなら，当面は ProtonMail をお勧めする。

暗号化メールサービスProtonMailの新規ユーザーが選挙後に急増、トランプ新大統領の不寛容を懸念 | TechCrunch Japan

私もしばらく前にアカウントを作っている。

ProtonMail のアカウントを作りました

SHA-1 の危殆化と OpenPGP V5

現在の OpenPGP は鍵指紋に SHA-1 を使用しているが， SHA-1 の危殆化に伴い「どーする？」ってな議論になってるようだ。

[openpgp] V5 Fingerprint again

参考図書

暗号技術入門第3版　秘密の国のアリス: 結城浩 (著); SBクリエイティブ 2015-08-25 (Release 2015-09-17); Kindle版; B015643CPE (ASIN); 評価

[Comment] SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。

reviewed by Spiegel on 2015-09-20 (powered by PA-APIv5)

Go 1.7.5 がリリース

2017-01-27T11:16:27+00:00

Go 1.7.5 がリリースされている。

Release History によると

go1.7.5 (released 2017/01/26) includes fixes to the compiler, runtime, and the crypto/x509 and time packages. See the Go 1.7.5 milestone on our issue tracker for details.

via Release History

ということなので，該当するパッケージを使っているプロジェクトは要対応である。

なお，併せて Go 1.8 RC3 もリリースされている。

Go 1.8 Release Notes - The Go Programming Language

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

[Comment] 著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Security Release Go 1.7.4 and 1.6.4

2016-12-02T11:32:33+00:00

数日前から予告されていたが， Go 言語の 1.7.4 と 1.6.4 がリリースされた。

[security] Go 1.7.4 and Go 1.6.4 are released

セキュリティ脆弱性を含むので（特に Web 関連で Go 言語を使ってる方は）必ずアップデートすること。なお，特に理由がない限り 1.7 系を使うことをお勧めする。

ひとつは crypto/x509 パケージに関するもの

もうひとつは net/http パッケージに関するものだ。

CVE 番号とかはまだ付いてないのかな？詳細が分かり次第，ここに追記する。

そうそう。 1.8 ベータ版も登場している。

GOPATH 環境変数にデフォルト値ができたらしい。あと go bug コマンドってなんだ？

週末スペシャル： Go コンパイラのセキュリティアップデートがあるらしい

2016-01-09T09:59:13+00:00

年末忙しくて書き損ねてるネタを回収中。

Go コンパイラのセキュリティアップデートがあるらしい

[security] Go 1.5.3 pre-announcement - Google グループ

詳細は示されてないが13日（日本時間だと14日かな）を待つことにしよう。来週は月例のセキュリティ更新週間である。

GnuPG 1.4.20 released

昨年の話で申し訳ないが

[Announce] GnuPG 1.4.20 released

セキュリティアップデートではないが既定の動作が変わるようである。

Reject signatures made using the MD5 hash algorithm unless the new option –allow-weak-digest-algos or –pgp2 are given.
New option –weak-digest to specify hash algorithms which should be considered weak.
Changed default cipher for symmetric-only encryption to AES-128.
Fix for DoS when importing certain garbled secret keys.
Improved error reporting for secret subkey w/o corresponding public subkey.
Improved error reporting in decryption due to wrong algorithm.
Fix cluttering of stdout with trustdb info in double verbose mode.
Pass a DBUS envvar to gpg-agent for use by gnome-keyring.

GnuPG というか OpenPGP が後生大事に MD5 を残しているのは過去の資産への対応のためであろう。

ちなみに PGP の最初のリリースは1991年で，実に四半世紀も前である。作者の Phil Zimmermann は当時，米国内反核運動の活動家であった。更に暗号技術に対する政治的圧力は現在と比較にならないほど厳しく，米国は長いあいだ彼をマークし続けた。 PGP の広まり方や改良のプロセスは実に「インターネット的」であった。詳しくは Steven Levy の『暗号化（Crypto）』をどうぞ。

あれからネットも随分変わったが，当時政府が何をしたか企業は何をしたか「暗号アナーキスト」たちはどうしたか。現在のネットは先人の努力により「勝ち取った」ものであることを私たちは絶対に忘れてはならない。

自由そのものは自由ではない。勝ち取ったものはいつか奪われる。奪われたくなければ勝ち続けなければならない。

GitLab.com にアカウントを作った

GitLab/GitLab.com 勉強会 (2015/12/09) レポート - Qiita

これ見て GitLab.com にアカウントを作ってみた。とりあえず中身は空っぽ。公開リポジトリを GitLab.com に作るメリットはない気もするが，容量が 10GB/repos あるのはありがたい。

まぁ，どう使うかはこれからおいおい考える。今年あたり，どっかにサーバでも借りて私用リポジトリ・サービスを立ち上げてみたいのだが，これもおいおい。

くそな「中間者デバイス」が SHA-1 廃止の邪魔をする

いやもうこれは笑うところだよね。

Barnes氏は次のように説明している。「ユーザーがHTTPSサイトへの接続を試みると、中間者デバイスがFirefoxに対し、サーバの本物の証明書でなく新規のSHA-1証明書を送信する」
「Firefoxは新規のSHA-1証明書を拒否するため、サーバに接続できない」（同氏）

「Firefox」、SHA-1証明書のサポートを一時的に復活--HTTPSサイトのアクセスに問題より

「SHA-1 衝突問題：廃止の前倒し」でも紹介したが， SHA-1 の危殆化はかなり現実的な問題になってきている。いますぐどうこうというわけではないが，これ以上の先延ばしは出来ない状態である。しかし CA やブラウザが頑張っても「中間者デバイス」なる覗き屋が邪魔をする。

やはりセキュリティ製品が暗号通信に対して「中間者攻撃」を仕掛けるのは筋が悪すぎると思うのだが，何とかならないものかねぇ。

参考図書

暗号化プライバシーを救った反乱者たち: スティーブン・レビー (著), 斉藤隆央 (翻訳); 紀伊國屋書店 2002-02-16; 単行本; 4314009071 (ASIN), 9784314009072 (EAN), 4314009071 (ISBN); 評価

[Comment] 20世紀末，暗号技術の世界で何があったのか。知りたかったらこちらを読むべし！

reviewed by Spiegel on 2015-03-09 (powered by PA-APIv5)

週末スペシャル： DELL よ，お前もか

2015-11-28T10:39:24+00:00

DELL よ，お前もか

あーあ。

Lenovo のときも書いたけど， PC ベンダ側がどう言い訳しようとも，これは純然たる「悪意」なの！

セキュリティ企業や組織は「脆弱性（vulnerability）」などと比較的穏当な表現をしているが，オレオレ・ルート証明書をインストールする行為自体が明確な「悪意」である。なぜなら（上述した通り）これは PKI の信用モデルに対する攻撃（破壊）だからだ。

Malware Spoofing HTTPS — Baldanders.infoより

ちなみに EV SSL も前提が崩れ始めていることをお忘れなく。

踊る PKI — Baldanders.info

Lenovo のときは「中国企業だから」なんてなこともちょっと思ったが， DELL もやっているとなると X.509 がいよいよ「バベルの塔」になる日も近いということかねぇ。

たしかに「プライバシーマーク」はクソだけど

この問題が複雑そうに見えるのは「プライバシーマーク」が本当にただの「マーク」で，ユーザから見てなんの役にも立っていないということだ。本来この手の認証サービスは相手が信頼できるかどうか不明な場合に第3者がそれを担保する仕組みなのだが，「プライバシーマーク」はそのようには機能していない。なぜなら，認証を受けた企業・組織が実際に条件を逸脱する行為をしたとしても「プライバシーマーク」はその逸脱に対して事実上なにもしないからだ。

企業が利益を追求すること自体は evil ではない。だがそれは他の企業・組織やユーザとの間に社会的な信頼関係があってはじめて成立し得る。その企業・組織の信頼性を客観的に示す方法はない。地道に「過去の実績」を積み上げていくしかないのである。これを「ブランド」という。

CCC のブランド・イメージはとっくの昔に壊れている。それは公共図書館運営に対する「嫌悪」とも言える反発を見ても分かることだ。「信用がない」どころかマイナスに振りきれている。それで「うちは独自のプライバシー・ポリシーで運営します」と言ったところで「あー，また CCC がやらかしてら」くらいにしか思われなくて当然だろう。

まぁ，私個人は今後も CCC は（プライバシー情報の運用に対して）信用しないし， CCC に加担する企業・組織も信用しない。

Google は Android 端末を解除できる

Googleはユーザーが所有するスマホの端末ロックをリモート解除可能と発覚 - GIGAZINE

なお，これには条件があって

レポートで判明した事実について、IT関連メディアのThe Next WebがGoogleに確認したところ、Googleが端末のロック解除をリモートで行えるのは「パターンで画面ロックされているAndroid 4.4搭載端末のみ」であり、PINおよびパスワードでロックしている端末についてはリモートで解除を行えないとのことです。

Googleはユーザーが所有するスマホの端末ロックをリモート解除可能と発覚より

ということらしい。 Andorid 5.x は暗号化されている建前だが，パフォーマンスがどうこう言うお馬鹿ユーザが多いせいか，暗号化されてない端末も多いようだ。 Andorid 5.x でも暗号化されてない端末には同様のリスクがある。

Google はユーザに対して「デバイスマネージャ」のサービスを提供しており， Google が画面ロックをリモートで解除可能だとしてもおかしくはない。また PIN コードやパスワードでリモート解除できないのであれば，それほどのインパクトではない。

対策としては

Android 端末は必ず暗号化を行うこと
盗難・紛失・没収の際は「デバイスマネージャ」を使い強いパスワードでロックすること

というところだろう。あと，端末の紛失を想定して「避難訓練」しておくのは有効である。

もちろんデータをクラウドに置いている場合はクラウドごとに個別に対処する必要があるし，そもそも携帯端末は tracking が容易であり警察・諜報組織は端末の中身が見れなくてもさほど困らないということをお忘れなく。

参考図書

信頼と裏切りの社会: ブルース・シュナイアー (著), 山形浩生 (翻訳); NTT出版 2013-12-24; 単行本（ソフトカバー）; 4757143044 (ASIN), 9784757143043 (EAN), 4757143044 (ISBN); 評価

[Comment] 社会における「信頼」とは。