兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしました（その1）
（追記）これまでの活動を時系列にまとめたTwitterのモーメントを作りました。記事はこちらで追えますので、合わせてご覧ください。
はじめに
先日、「forループでalertウィンドウを出すだけ」という、いわゆるジョークプログラムへのリンクを張った3人が、兵庫県警によって1名(未成年)が補導、2人が書類送検される予定という事案が発生しました。(for文無限ループURL投稿で補導された件についてまとめてみた)
この事案について、兵庫県警に対し兵庫県情報公開条例に基づいて以下の情報公開請求を行いましたので記録します。
なお本記事については、以前に同様に神奈川県警に対して情報公開請求を行った 梅酒みりん 様へお願いし、文面について利用させて頂くことを快諾頂きました。この場を借りて感謝を申し上げます。
公文書公開請求書
内容（スクリーンショット）
請求した公文書
兵庫県警において刑法第百六十八条の二又は第百六十八条の三（不正指令電磁的記録に関する罪）に基づく取締りその他の運用を行うにあたり、どのような内容をもって犯罪行為とするかの構成要件等を記載した文書（具体例を含む）
到着確認
簡易書留で送付したため、到着を追跡し、受取確認済みです。
今後の流れ
今週中に、いちど兵庫県警へ電話し、到着しているかを念のため確認予定です。また今後、全ての流れはブログに記載します。
よく聞かれるであろう質問
先に答えておきます。
あんた誰
Web系企業で、セキュリティエンジニアをやっています。専門は脆弱性診断(セキュリティ診断、セキュリティテスト)とペネトレーションテストです。Twitterはozuma5119です。
また、すみだセキュリティ勉強会というセキュリティ勉強会を、個人で主催しています。
なぜこのような請求をおこなったのか
はじめに、知らない方のために脆弱性診断について説明します。
脆弱性診断とは、セキュリティ診断・セキュリティテスト等とも呼ばれ、実際に悪意のある攻撃者が利用する手法・ツールを用いてシステムの脆弱性を発見するものです。また、「侵入できるか」に特化したペネトレーションテスト(Pen Test)も同じ仲間に入ります。(Pen Testが脆弱性診断に含まれるどうかは、実は人によって考えが違い宗教論争なので深くは語りませんが、ここでは仲間に入るとします)
理由その1：私は逮捕されたくないからです
私は自身が勉強会を主催していることもあり、実際の攻撃手法の解説や、脆弱性をどう利用するかといったブログ記事を書いています。しかし昨今の事例を見ると、このような行動が違法行為とみなされ、警察に逮捕されるという事案が頻発しています。当然ながら私は逮捕されたくありません。本事案は「このような行為はセキュリティを専門とする者の萎縮を招く」などと各種メディアで書かれましたが、既に私は萎縮しており、次の勉強会の開催をいったん保留しています。
そのために、何をやったら犯罪なのか、まずは兵庫県警の考えを知りたいのです。
また私は仕事や個人でアメリカに年何回か行きますが、アメリカは過去に逮捕歴があるとビザ無し渡航が不可となります(私は過去に逮捕されたことがあります。ビザなしで渡米できますか？)。つまり出張のたびにビザを申請せねばならず、仕事上、大きな支障をきたします。ですから逮捕は避けねばなりません。
理由その2：私の大切な友人たちを守るためです
私は職業柄、多くのセキュリティエンジニアの友人がいます。彼ら彼女らは、各種ハッキングツールの使い方を講演したり、ブログ等でどのように攻撃が成立するかレポートを書いたり、勉強会にて脆弱性を利用した攻撃方法の研究を発表したりしています。
今の状態を放置すると、そのような私の大切な友人であり、日本のサイバーセキュリティを守るべき高度人材が、無知な警察に逮捕されるという最悪の事態に陥ってしまいます。そのためにも、まずは逮捕されないように無知な警察から自衛する必要があるため、何を根拠に犯罪とみなすかの情報公開を請求した次第です。
なお、このような無知な警察による逮捕という異常事態が続いていることを私は重く見ており、時間とお金に余裕があれば、47都道府県すべての警察に情報公開請求をしたいと考えています。
そういう目的のために情報公開請求ってあるの? 嫌がらせっぽくない?
日本は国民の「知る権利」を根拠として47都道府県すべてにおいて情報公開条例を定めており、行政機関が保有する情報の公開を申請することは、なんら法的に問題ありません。むしろ条例を定めた意義をくみ取り、積極的に利用することが望まれます。
兵庫県警から回答が来たら、ブログ等で公開しますか?
兵庫県警から何かしらのコンタクトあればその内容を含め、すべての内容はブログで公開します。また公開された文書はスキャンし、すべて公開します(「非公開」の回答となるかもしれませんが)。それこそが情報公開条例の目指すところであり、一市民の果たす義務です。
万が一、「この内容はブログに書かないように」という発言が兵庫県警からあれば、そのような発言があった旨をブログで公開します。
○○した方がいいよ! ××ではダメなのでは?
今回の情報公開請求は、「非公開」の回答が来ることが予想されます。その場合は、引き続き次の一手を打ちます。その際は当然のことながら、兵庫県警の様々な「隙」を利用します。ですから、その「隙」を少しでも感づかれたくありません。
そのため、アドバイスはありがたいのですが、そこに回答をしてしまうと私の次の一手を兵庫県警に予測され、先回りされて手を打たれてしまう可能性があります。よって、コメント欄は閉じておりますし、Twitterでもそのようなリプには一切返信をしておりません。
とはいえ、私は法律の専門家では無いので、法律の専門家の方や、同様事例の経験がある方のアドバイスはありがたいです。アドバイスをしたい方は以下のGoogleフォームからご連絡ください。
ただし、兵庫県警の職員が一般人を装って投稿する可能性があることから、こちらからの返信は一切しません。ご理解ください。
あなた東京都民でしょ? 兵庫県関係なくない?
（その2に続く）
次世代Webカンファレンス 2019：HTTPSセッションが面白かった
以前から気になっていた「次世代 Web カンファレンス 2019」を、ようやく聴きに行くことができました。
たくさんのトークがありましたが、ここではHTTPS (hashtag: #nwc_https)をメモしておきます。なお、このセッションが間違いなく一番アツく、一番面白かったです!
以下、当日参加した、もしくは動画を見たという前提でのメモなので、見てない人はぜひ見ましょう。
PKI
「低レイヤから行きましょう」ということで、はじめはPKI絡み。Symantecのdistrustと、日本のGPKIの話でした。
トーク中に何度か出てきましたが、認証局(厳密にはCAとRAを分けて書くべきですが、どうせみんな一緒なので敢えてこの文章では分けてません。念のため)の基本要件となるCA/Browser ForumのBaseline Requirementsというドキュメントがあります。証明書を扱われる方は一読を。
Symantecのdistrust事件
細かい経緯は既に多く書かれているので省略します。
現在、Google ChromeおよびFirefoxでは、Symantecおよびその関連会社の発行したSSL証明書を利用したWebページは、エラーとなって表示できません。ここでは、Symantecの関連会社であるThawteとGeotrustの例がありましたので紹介しておきます。
これらのページをGoogle ChromeもしくはFirefoxで開くと、証明書エラーとなります。
なおこのエラー画面のために、FirefoxもChromeも、どちらもわざわざ固有のコードを埋め込んで実装しています。特にChromeはFirefoxと違いブラウザ内にトラストストアを持っていないので、本来はOSの「信頼されたルート認証局」をトラストアンカーにするのですが、わざわざこのためのエラーコード NET::ERR_CERT_SYMANTEC_LEGACY を定義して証明書をチェックしています。
net_error_list.h：
// The certificate chained to a legacy Symantec root that is no longer trusted. // https://g.co/chrome/symantecpkicerts NET_ERROR(CERT_SYMANTEC_LEGACY, -215)
一方、Safari, InternetExplorer, Microsoft Edgeは通常通り表示されます。Googleのdistrust宣言に乗っていないからですね。
ただしEdgeは将来Chromiumベースとなるため、将来は同じ挙動となります。その頃にはもう、Symantecの証明書はこの世に残っていないと思いますが。
トークでは皆さん遠慮して言ってなかったのですが、たかが(と敢えて書きます)一企業に過ぎないGoogleがdistrust宣言をすることで、巨大CAをあのようにいとも簡単に潰してしまうことが本当に正しいのか。私としては、むしろ「Google怖い」というのが素直な思いです。
この先、未来永劫Googleが正しい判断をして正しい行いをする保証などどこにもありません。Chrome/Chromiumが寡占状態になったとき、Googleに敵対する企業が認証局ビジネスをやっていたら……それでもGoogleは公正にふるまい続けるでしょうか。私にとっては、Certificate Transparencyと合わせて、「Google怖いな」という思いをすり込まれた思い出が残ります。
GPKI
こちらも、詳細はブログにまとめられている方がいらっしゃるのでそちらを紹介します：
GPKIは日本政府謹製の認証局でしたが、そちらの運用が上手く回っておらず、Firefox(というかmozilla)の信頼するroot CAから外されてしまったというものです。ここで問題視されたのは、失効処理(Revoke)です。
Baseline Requirementsでは、認証局は自身の発行する証明書に問題があるのではという報告を受けた場合、24時間以内に調査を実施し、問題があれば失効させなければいけません。しかしGPKI側は、「いや、どうせ待ってればExpireして失効するから、そのままにしておくという」という回答をしてしまいました。これでは認証局として適切な運用がなされていると判断できないため、GPKIはMozillaにroot CAと認められませんでした。
ただこの時のメールのやりとりを見ていると、担当者の方を責める気にはとてもなれません。私もかつてSIerで官公庁周りのシステムを触ったことがありますが、本当に神経を使いますし、そう簡単においそれとシステム変更などできません(証明書入れ替え、という定型作業であっても)。
GPKIがかつて使われていたところは現在、その多くはセコムの証明書を使うことで落ち着いています。実際、認証局の運用をわざわざ官庁でやる必要は感じられませんし、その費用を考えたらセコムから買った方が安いでしょうから、合理的な判断だと思います。
ちなみにアメリカの例では：
- NSA https://www.nsa.gov/ → Let's Encrypt
- FBI https://www.fbi.gov/ → COMODO
- WhiteHouse https://www.whitehouse.gov/ → Digicert
となっています。NSAがLet's Encryptというのは面白いですよね。
これからの認証局
司会のjxckさんからは、これからCAはどんどん減っていってしまうのではという意見が出ました。これはmozaic.fmでもおっしゃってましたね。EV証明書もなくなっていくかもしれない、認証局はとても高いセキュリティレベルが求められてちょっとでもミスると徹底的に叩かれる、このような状態で新規参入したいところも無いだろうし寡占状態となるのでは、と。
しかしこれに対して、むしろCAは増えている、というのはちょっと驚きでした。そういえば、確かにAmazonも始めていた。そしてGoogleですが……これはトークでも触れられていましたが、WebブラウザもOSも作っており、Webサービスもやっている企業が、認証局もやるというのはちょっと「おかしい」よなと私も思います。
あとEV証明書については、Stripe Inc、というキーワードだけ挙げておきます：
TLS 1.3
TLS 1.3については、確かに後方互換性を確保するために、これまでに無いパターンで大規模実験しながら作っていたなぁという感想です。実際、導入に乗り気であったFacebookは、わざわざ https://www.tls13.facebook.com/ というTLS 1.3テスト用の環境を用意しました。(これを使っていた人、どのくらいいるかな。RFCドラフト段階でテストするために作られたので、かなり前からあります)。
NW経路途中のファイアウォールやロードバランサなどのアプライアンスを引っくるめ「ミドルボックス」と呼びますが、これで叩き落とされないようにするため、TLS 1.3は一部にちょっと変なところがあります。
例えばTLS 1.3のServerHelloは、Handshake時のVersionを0x0303(TLS 1.2)と応答します。ただしsupported_versionsというExtensionをくっつけて、この中でVersionを0x0304(TLS 1.3)と指定します。これは、一部のミドルボックスでServerHelloに素直にTLS 1.3と指定すると通らないことが分かったためです。このように、見る人が見ると「ツギハギ」に見えないことも無いのですが、そのぶんTLS 1.3は強力な後方互換性を持っています。
「TLS 1.2は、そのまま残す。そしてTLS 1.3は改良していって、TLS 1.4, TLS 1.5...となっていくんじゃないかな」というの初耳で、なるほど～と思いました。一つの理由は、kjurさんのおっしゃったようにIoTデバイスなど。そしてもう一つの理由として、4maさんが強調されていましたが、セキュリティは常にalternativeが必要という観点。
これから先、TLS 1.3のプロトコル自身に致命的な脆弱性が見つからないとも限りません。だから何かが見つかってしまった場合、スイッチするために選択肢は最低2つ無いといけない。TLS 1.2はその命綱として生き続けるでしょう。
ちなみにTLS 1.3利用率の伸びは、kjurさんの作られているSSL Pulseをグラフ化したページで見ることができます。
TLS 1.3は現在10%ほどで、ほとんど横ばいです。ほぼFacebookのトラフィックではないか、とのこと。
※上記↑、kjurさんより指摘いただき、「上記SSL Pulseのグラフはトラフィック数ではなく、サイトの数となります」とのことでしたので修正します。
SXG(Signed HTTP Exchange)
これも初めて聞いたときは、「怖い! Googleを批判する記事を、Chromeがわざとエラー出すことできる!」と真っ先に思った技術です。(私は陰謀論者なので、すぐにGoogleと陰謀を結びつけてしまうのです。ただのクセなのであまり本気に取らないでください)(こういう注意を入れないと、面倒な世の中なので)
確かにCDNからの配信でかなりアドバンテージあるとは思うのですが……。証明書がExpireしそうになったときの更新など運用面が、これまでからまるっきり違ってくるので、普及するとどういう世界になるのか正直よく分かりません。
参考リンクとして以下を挙げておきます。Turing Complete FMは面白いのでメッチャおすすめ。
量子コンピュータ
詳しく無いので、jovi0608さんのこのツイートが面白いので貼って済ませます。
Internet Week 2017の「知らないと困る？！認証局とHTTPSの最新技術動向」では、今後バズりそうな量子コンピュータ・耐量子暗号とTLSの関係についてもこんな話をする予定です。まだ残席ありますので興味のある方は是非。 https://t.co/h1U6KVtO2N pic.twitter.com/Y1wScDq3km
— Shigeki Ohtsu (@jovi0608) 2017年11月16日
素因数分解ができるのでRSA暗号が崩れるというのは有名な話ですね。AESなど対象暗号で、充分bit数を上げれば大丈夫、というのは理解があやふやだったので助かりました。
その他
ごはん
おひるご飯は重要です。大学周辺の飲食店は日祝休みとなるため、靖国通りまで出て前から気になっていた「黄金の塩らぁ麺 ドゥエイタリアン」というラーメン屋に行きました。
ラーメン屋ですが店内はイタリアン風で、生ハムにチーズたっぷり、オリーブオイル仕立てのラーメンでした。チーズ好きな人は大歓喜でしょうが、私は、なんというか、アレですな、ラーメンは横浜に限りますな。
信頼
最後にjovi0608さんが信頼(Trust)について強調されていたので、誤解される方が出ないよう少し書いておきます。
少なくとも現在、たとえEV証明書であっても、「信頼」はあくまで技術用語としての信頼(すなわち、ある証明書を、ルート認証局の証明書からのチェインでちゃんと検証できる)という意味以上は持ちません。これは誤解を招かないように、CA/Browser ForumのEV SSL Certificate Guidelinesでも、Section 2.1.3の"Excluded Purposes"で、「EV証明書で目的としないこと」という節をわざわざ設けて説明しています。
このSectionでは、EV証明書のSubjectへ以下の4つを保証することを、EV証明書では目的としていない(だから、誤解すんナよお前ら)」と明記されています。
- That the Subject named in the EV Certificate is actively engaged in doing business; (実際にビジネスを行っていること：つまり、フィッシング目的などペーパーカンパニーではないこと)
- That the Subject named in the EV Certificate complies with applicable laws; (法律に準拠していること)
- That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings; (信頼できる公正な商取引を行っていること)
- That it is “safe” to do business with the Subject named in the EV Certificate. (ビジネスを行って「安全」な相手であること）
(4は1-3で内包される気もするので、ちょっとしつこいですね)
ペットボトル
学生さんへのメッセージですが、見ての通りみんな普通にペットボトル置いてガブガブ飲んでいます。変なマナー講師の言うことを真に受けるのはやめましょう。
終わりに
大変に楽しくエキサイティングなトークでした。聞きに行って良かったです。発表者の皆さま、ありがとうございました。
すみだセキュリティ勉強会2018その3を開催しました
また前から日が空いていまいましたが、すみだセキュリティ勉強会2018#3を開催しました。
私の発表は「Data Privacy Day - Googleを使わず1日過ごしてみる」です。
Chrome 69では、「google.comへのログイン」と「Chromeへのログイン」を曖昧にする変更が議論を呼びました。この話題に絡めてGoogleがどれだけ情報収集を行っているかの解説と、昨今のPrivacy重視のプロダクトの紹介として、DuckDuckGo, ProtonMail, brave browserあたりの紹介です。特にProtonMail, ProtonVPNは、FirefoxがProtonVPNを採用したこともあり、今後伸びていくプロダクトではと思っています。
Privacy重視のWebサービスは、当然のことながら行動ターゲティング広告を行うプロダクトに比べると、どうしても不利な情勢にあります（主に資金面で）。ということで、躊躇無く課金して応援して行きたいものです
また、発表いただいた@saiyuki1919さん、@morihi_socさん、そしてお越し頂いた皆様、ありがとうございました。
HTMLのid属性に日本語は使えるのか
先日、東京五輪ボランティア応募サイトを検証したら予想以上にヤバかった（語彙力）という記事を読んでいたところ、日本語をid属性に使うことが槍玉に挙げられていました。
しかし日本語だろうがギリシャ語だろうがASCII文字だろうが、Unicodeの1文字であることに変わりはありません。最近は多言語対応が十分に進んでおり、今さらASCII文字しかダメなんて時代遅れなこと本当にあるの? と思い少し調べました。
先に結論
id属性に日本語を使うことは何も問題ありません。
調べてみる
件のボランティアサイトは、HTML 5で記述されています。
ということで、W3CのサイトでHTML 5の仕様書を確認してみましょう。現在の最新版は、HTML 5.2です。
id属性
id属性は、DOMのところに記述があります。
ここでid属性の制限は以下のように定義されています。
When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element’s tree and must contain at least one character. The value must not contain any space characters.
つまり、
- id属性は一意でなければならない
- 最低1文字でなければならない
- 空白文字を含んでいてはならない
以上が制限です。
さて、このような技術文書を読む際は、用語の定義に注意が必要です。ここでは無造作にcharacterという単語が使われていますが、この文書でのcharacterにはどういう制限があるのか、定義の確認が必要です。
HTML 5のcharacterとは
characterの定義は、「2.1.6. Character encodings」に書かれています。
In this specification, the term character, when not qualified as Unicode character, is synonymous with the term Unicode code point.
このように本仕様書では、"character"という用語は、（「Unicode文字」と書かれていない場合は）Unicodeコードポイントを意味すると書かれています。日本語には当然Unicodeコードポイントが割り当てられていますから、characterに該当します。よって、id属性に日本語を使うことは仕様上なんら問題ありません。
