TLS1.0クライアントライブラリでCBCを使えるか考えてみるメモ（訂正版

TLS1.0のクライアントを何とかBEAST対策させる方法として。
# なんでこんな事を検討してるんだとかはあまり考えたくないのでやめておく
# ブラウザではないのだけど

そのままランダムバイトシフトによる方法は効率が悪い。というのを昨日気づいていなかったので訂正を兼ねて。

CBCでは
平文ブロックの列 ..., Pn-1, Pn , Pn+1, ...
暗号ブロックの列 ..., Cn-1, Cn , Cn+1, ...
に対して、
E( Cn-1 ^ Pn) = Cn
がなりたつ。

BEASTでは
(1) 攻撃者はブロック境界を制御できる
(2) ある平文ブロックPxに秘密情報が1バイト含まれ残りの部分は知っている
(3) かつある暗号ブロックCn-1に対して、次の平文Pnを制御できる
(4) 次の平文Pnを攻撃者が決定する前に、Cn-1とそれ以前の暗号文ブロックを傍受済み
を組み合わせる。

攻撃者はPxブロックの暗号文Cxを傍受できるが、直接残りの1バイトを計算することはできない。そこで攻撃者はセッションを再利用して平文Pnで始まるリクエストを発行する。
このとき、次の平文Pnとしてブラウザに送らせるべき内容は、想定している256種のPxの一つ Pxi (i= 0...255)について、Cn == Cxを仮定して、Pn ^ Cn-1 == Pxi ^ Cx-1 から、Pn = Pxi ^ Cx-1 ^ Cn-1 と計算できる。(4)からCn-1を傍受できるので、Pnを計算するための不確定要素はPxiの256通りのみになる。

Cn が予想通り Cxと一致すれば、 Pxiが正解だったことが分かる。失敗であれば、盗聴した最後の暗号ブロックを新たにCn-1として、次のPxiを調べていく。つまり平均128*トークン文字数程度の連続リクエストができればPxiから衝突を発見できる。トークンが事前にhexとわかっていれば、平均8リクエスト*トークン文字数ですむ。


TLS1.1以降で導入されるIVの強制的な更新では、暗号鍵・セッションを再利用する場合、新しいリクエストでは以前の暗号ブロックCn-1を使わず新しいIVにすることで、バイトごとの総当りを不可能にする。つまり(4)を防ぐ。攻撃者は新しいIVを事前に知ることが出来ないので、適切なPnを生成できない（Cn-1が足りない）。

TLS実装側から言えば、CBCモードの暗号器を使うなら、平文入力をバッファして次の平文ブロックPnが確定するまで直前の暗号ブロックCn-1の出力をブロックし、平文バッファをフラッシュしてMACを送った後はIVを変更することで、（4)が成立しないことを保証する。


TLS1.1に対応したクライアント・サーバーならこれでいいが、CBCがデフォルトのままのサーバーと、TLS1.0クライアントライブラリを使わなければならない場合を考える。

まずTLSセッションを毎回破棄してしまう方法があるが、keep-alive必須とされているし、お互いにあまりにも効率がわるい。
openssl実装は設定によってはパディングを送信できるようだが、少なくとも（TLS1.0しかない）1.0.0でがデフォルトにはなっていないようだ。

クライアントだけで出来る一つは、冗長なリクエストを送ることで、IVの更新に替える。たとえば、全てのリクエストの前に、/へのHEADリクエストを送るなど。続くjavascriptで生成されたリクエストはHEADリクエストの最後の暗号ブロックをIVとして使うので、攻撃者はPnを生成できない。なおN回に1回HEADを送るのでは、攻撃を'(N-1)/N倍に遅くすることしか出来ないのでほぼ意味が無い。

これらはいずれも(4)を防ぐことでBEASTから守る。


一方、追加ヘッダで可変長の乱数列を追加する方法は、攻撃者がPxの状態を知ることが出来るという前提を崩す方向を考える。つまり(2)のPxの特定を難しくする。これははっきり行って効率が良くない。

乱数列の長さが不明なので、攻撃者はPx候補の前の暗号化ブロックCx-1を複数のブロックから見つけ出す必要がある。
これが成功する確率は、乱数列のバイト数をkとし、秘密が1バイトだけで左15バイトが既知なら、1/kになる。よさそうだが、2バイト目への攻撃もまた1/kで推定できてしまう。つまり困難性はk/2倍程度しか上がらない。

200バイト可変シフトさせて、突然クライアントからのリクエスト数の桁が100倍も増えれば、流石にレートリミットが効くだろうけれど、全体平均してk/2倍にしかならないので暗号としては余裕が無い。もっとも、Cookieに保存するトークンの長さを(k/2)倍にするのと同じだけの効果がある、という意味では大きい。

バイトシフトによる対処では足りないなら、秘密情報の位置をシフト「させない」必要が出てくる。同一ブロックに３〜４バイトも秘密情報が含まれれば、総当りは急激に難しくなる。つまり(2)の不確定要素を2バイト以上にする。
だがこれはjavascriptがcookieをセットできるのでうまく行かない。javascriptで重要なトークンより前に別のキーをセットしたり、長さを変更できてしまう。


結局のストリーム暗号としてのCBCモードの限界として、クライアント側で使えそうな防御手段はあまりない。
弱い暗号やCBCを強制するサイトからは都度ログアウトする、くらいか。

Fedora+munin+Fastcgi+nginxで統計表示するメモ

muninの設定でハマったのでメモ
Fedora17 + EPEL にパッケージの設定をなるべく変更せず導入する。

インストールは
yum install nginx munin munin-fastcgi-html munin-fastcgi-graph
FastcgiやPerlモジュールは勝手に入るはず。

munin側の設定

/etc/munin/munin.conf
にコメント例のとおりにサーバを記述するのと、

html_strategy cgi
graph_strategy cgi
cgiurl_graph /munin-cgi/munin-cgi-graph
cgitmpdir /var/cache/munin

を変更or追記

cgitmpdirは手動で作成。chown munin:muninしておく
このフォルダと設定が無かったため一日分のログが取れてなかった……。


FastCGIの設定
fastcgiはapache前提になっているので
/usr/lib/systemd/system/munin-fastcgi-*
の中のソケットユーザを -U apache から-u nginx に変更しておく
systemdをリロードしてそれぞれスタート。


nginx側の設定
適当なアクセス制御をしたことにして

location ^~ /munin-cgi/munin-cgi-graph/ {
fastcgi_split_path_info ^(/munin-cgi/munin-cgi-graph)(.*);
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass unix:/var/run/munin/fcgi-graph.sock;
include fastcgi_params;
}
location /munin/static/ {
alias /etc/munin/static/;
}
location /munin/ {
fastcgi_split_path_info ^(/munin)(.*);
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass unix:/var/run/munin/fcgi-html.sock;
include fastcgi_params;
}

nginx -tして問題なければstart

これで /munin/にアクセスすれば動くはず
配置を返るのはmunin.confのhtmldirなどで。

ServersMan@VPSでunbound構築メモ

アルコール入りの勢いで一気に構築しなおしたのでメモ。

環境はEntry 東京ロケ、CentOS6 32bit。kernelは2.6.18-el5だった。ぐぐると初夏のメンテでほとんどは2.6.32 (Centos6?)にアップデートされているらしく、どうもアップデート漏れのホストにあたってしまったらしい。

まずデーモンの掃除。sshdを設定するまではajaxtermは一応残す。
リブートしてsshdに証明書ログイン確認次第不要サービスを切る、serversman、netfs など勝手インストールされているものを切る。最後に ajaxterm httpd。

手元のVMで試したiptablesをiptabls-saveして転送、iptables-restoreして問題が無ければservice iptables save。元のiptablesは空だった。
が、ここで-m stateは通ったものの、stringやu32は利用できず。
DNS Amp踏み台にされそうなので出来れば設定したいところだけれど、ググってみた限りサポートは今後も期待できなさそう。

ipv6 はそもそもip6tablesモジュール自体入ってないようなので、ipv6無効に。各サービスも一応インターフェースは静的にセット。

yum.repos.d に EPELを追加。
unboundはEPELにあったが、1.4.16で使えない設定が多いためrpmをビルドする。（minimalとかforward firstとか）
http://blog.tnmt.info/2011/04/29/rpmbuild-for-beginner/
を参考にしつつ、
unboundのソースを落としてSOURCEに入れ、unbound.specのバージョンを更新、古いパッチを消してビルド。
configure時に追加で--disable-ecdsaの追加が必要だった。

なお、serversmanがopenssl0.9.8を必要としていてビルドに差し障ったかもしれないので、openssl0.9.8は削除してopensslとdevelもリインストールしておく。

できたrpmをインストールして1.4.19の動作を確認。ひとまず問題なく動いている模様。
キャッシュを少なめに、usedが512MB超えないようにチェックしつつ軽く負荷をかけてチェック。

pingはそこそこ早いようなので十分か。

問題としてはvnetの制限なのか、libpcapがクラッシュしてキャプチャが出来ない。検出ミスチェックに便利なのだけれど。こればかりは完全仮想化にしておけばよかったかも知れない。USにもう一台設置するとしたらkvmにしよう。256MBあればなんとかなる。きがする。

高木先生に解釈の相違を頭がおかしいのではと非難された件について

不正指令電磁的記録、いわゆる「ウイルス」に関して、高木先生とやり取りして感じたことをまとめてみる。

高木先生は全国電話帳の件について、どこにも端末の電話帳が利用されることは記載されておらず、違法であると考えているようだが、

http://secroid.jp/d/e/a/c/info.jigensha.hellopage.html
https://twitter.com/cause_less/status/263678476920442880
について以前のエントリやツイートで書いたように、自分は全国電話帳のアプリ説明は誤認を誘導するために複数の読み方が出来るように書かれていると考えている。

日本語には単数と複数の区別がなく指示語の曖昧さがあるので、「アプリ利用者」という単語だけでは、利用者個人をさすのか、全ての利用者全体を指すのか区別できない。Google Playのアプリ説明はアプリの一般的な解説を意図しているので、アプリ利用者は当該アプリを利用している全ての人間を指す可能性があり、個人を指すと断定することが出来ない。
アプリ利用者「本人の」、と補って解釈すれば他人のアドレス帳から検索できた時点で明らかに違法であり、「全員の」といれれば逆に合法の可能性がある。

高木先生は他の読み方はあり得ず、自分のような解釈をするのは頭がおかしい、と言われるが、不明確な用語の利用は高木先生も各種サービスの利用規約の問題点として指摘されている通り、一見問題無さそうな文章でも、解釈によっては悪用されうるということは、（すくなくともサービス開発や運用に携わる人には）一般的な認識になっていると思う。あるいは、そう願う。
他の解釈はあり得ない、という考え方は、一方的な断定であると思う。

全国電話帳アプリに利用者を騙す意図が有ったことは本人の言から明らかで、ソフトウェアの社会的信頼を毀損する意図が有ったことは明白だが、悪意と違法性はイコールではない。違法でなければ何をやってもいいという考え方は倫理的に好ましくないが、反社会的な悪意を直ちに違法と見なすことはより好ましくないと自分は考えている。

不正電磁記録はアプリ利用者の意図と反する挙動をするソフトウェアであって、「アプリが本来どのような動作をするべきか」を判断する際に立場によって解釈の相違が生じうる。
極端に解釈すれば、ソフトウェア解説が他言語で書かれていて、利用者が読めないにもかかわらず実行可能な場合はすべて不正電磁記録と見なすことさえ出来る。
アプリ利用者がどの程度の前提知識を持ち、どの程度アプリの解説を読み、どの程度の操作（同意ボタンなど）をもって同意と認めるのか。逆に言えば、どのような解説や規約・同意判定を実装すれば不正電磁記録に当たらないのかは、判例なり明確な判断基準が示され、実際に法廷で争われるまで分からない。
個人的に、この不正電磁記録の考え方は「法律の穴」と言っていいレベルの瑕疵だと思っている。

識者と目される方が、違法かどうかを判断する上で一方的な解釈のみを採用し、「解釈の相違」という法律の穴から目をそむけるような態度をとるのは、問題が有ると考えている。
現状、識者が悪意をもって「このアプリの挙動は私の解釈に反する」と告発すれば、大抵のソフトウェアは違法にできてしまえるのではないだろうか。

匿名の自分に、法解釈について議論できるほどの知識も資格もない、と言われることは大いに予想できることだが、逆説的に、一部の有識者による一方的な解釈によって個人の行為が違法にされうる、という不安をソフトウェア開発者の一人が感じていることを理解いただければと願う。

NEC Aterm WR8370Nの挙動

USBメモリ簡易NAS機能やGbEハブ、あとWakeOnLAN対応とスペック的には満足して買ったAtermのWR8370Nの不満点を幾つか書いてみる

ループバック接続ができない
LAN内のPCからWAN側公開ポートに接続できない。外部IP、からならアクセス出来る。
Local IP spoofingと判定されブロックされているらしいのだが、それらしいセキュリティ機能をオフにしても何故か接続できない。
NAPTの仕様らしい。

ポート23と5432が開いている
LAN側で何故かtelnetの23, pgsqlの5432が開いている。telnetは保守用らしく、ファーム解析等で調べた人が居るようだ。
流石に現在はパスワードは変わっているらしく、MACからHMACなりで出すんだろうと思う。
でも、何故にDBが動いているのやら。syslogあたりならまだわかるけど。
#まさかペアレンタルコントロールフィルタ用とかじゃないだろうな……

WAN側ポート80が開きっぱなし
リモートでのWakeOnLan機能をオフにしても開きっぱなし。フィルタで80を破棄に設定しても無駄だった。

家庭用だから仕方ないとはいえ、色々怖いのでもうちょっと何とかならないものか

停電に備えたLEDライト購入指南的メモ

を騙る電子工作ヲタの趣味のマトメ
（これは国内製品よりも個人輸入による中国直販LEDライトも含めた話です。）

・単一のLEDを使用し、LEDのスペックで輝度をCd（カンデラ：照度・明るさ）ではなくLm(ルーメン：光量・総量)で記載されているものを選ぶ。
明るさはレンズで集めたり近くで測ればいくらでも明るくなる。一方Lmを偽装するのは（少なくとも国内では）明らかに違法になる。
また、LEDの数か多いと、電圧を均一化する過程でロスが増える。また、LEDの半導体の効率を無視してパッケージ数の方にお金をかけているだけなので、コスト的にも良くない。

・電池はニッケル水素充電池を用意する。
LEDライトは一気に大電流を必要とするが、内部抵抗の大きいアルカリ電池（マンガンは論外）では、大電流を流すと出力電圧が下がってしまう。
エネループなどの充電池を使い、あらかじめ充電しておく。エネループなどLSDと呼ばれるタイプの新型電池は１年くらい放置しても大丈夫。

・単三電池１本、できれば２本で動作するもの。
LED趣味の人間の間で安価なクラス（2000円くらいまで）のLEDライトでは、電池一本1.2Vから1.5A程度の電流を取り出す(大電流なのでさらに効率は落ちる)。
出来れば単三・二本で駆動するタイプが持続時間的に望ましい。
単4電池は800mAh程度しか無いので、携帯用として常備するならいいかもしれない。

・teil stand (机に逆さに立てられるもの)
円筒状のLEDライトの底面を工夫して、机の上におけるものが多い。白色が多い天井に反射させて一時的な明かりとして使うわけだ。まあ構造上立たなくても、グラスなりで無理やり立たせればいいとも言う。

・曲面レンズを持たないもの
レンズ付きで集光能力の高いタイプと、ミラーだけで曲面レンズの無いタイプがあるが、後者が好ましい。
前者は遠くの狭い範囲を照らす場合、例えば、ナイトロードでの前照灯や、警備員が外から窓の締め忘れをチェックするような場合に使える。
後者は広い範囲をほぼ均一に照らすため、真っ暗な夜道などで足元を照らしたり、ものを探したりする時に役に立つ。
殆どの人は、ミラー式でレンズを持たないタイプをまず買ってみる事をおすすめする。

・フラッシュが無いもの
点滅するフラッシュモードを持つ製品が多いが、実際に役に立つことはほぼ無い。遭難した時にヘリに向けて気づいてもらうくらいにしか役に立たない。
100%と10%点灯の強弱２モードくらいで十分。

・表面処理の良い比較的高級品か、ステンレス製のもの
大抵アルミ製に安価なコーティングがなされている。高級品はそれなりに傷つきにくいが、安物は……。
ステンレスは重いが傷つきにくく、コンクリに落としても内部パーツが割れなければ問題なし。

・最新LEDを採用しているもの
特にCREE社のLEDは製品ラインによって全く効率が違う。今、明るさを求めて中国直販をするならXM-Lシリーズを狙うといい。
もっとも、室内利用を前提にするならXP-Cといた数世代前でも十分で1000円以下で手に入る物も多い。

中国直販では
Balder SE-1 $28くらい　（テールスタンドは非対応だけれどそこそこ安く明るい）
UltraFire C3 Stainless Steel $13くらい （ステンレス製。古いがシンプルで安い。フラッシュがあるのが難点）
あたりが手頃で無難とおもわれる。

なお、このクラスのLEDライトは直視すると本当にやばいのでお気をつけて。
（LEDの光を手に当てると暖かく感じるくらい）

交絡の排除と推定分布の信頼区間は別物

サイエンスライターが交絡を無視するのは不味いと思ったので書いておく

とある同じ病気の病人のグループを病院A、病院Bの2グループ10人ずつを用意し、Aには薬aを、Bにはプラセボを与えて観察した。
AとBとで生存率に統計的有意差が無かった（または有った）。
薬aの効果（生存率と投与量の因果関係）の有無を示すことができるか？

もしかしたら、
効果が有るようにみえて、実は病院Aは体力のある若い患者が多く、病院Bは体力のない老人が多かったかもしれない。
逆に、効果が無いようにみえて、病院Aは体力のない老人が多かったかもしれない。
つまり、病院と患者の生存率に交絡がある可能性がある。従って、これだけで薬の効果を判断することは出来ない。

ここで、各グループの人数を10倍に増員して、90人ずつ追加で実験したら、結論は変わるだろうか。
実験対象患者数が増えるので各グループから推定される生存率とその分布、つまり推定生存率の信頼区間は小さくなり、精度がよくなるだろう。もしかしたら見えなかった有意差が見えてくるかもしれない。
しかし、交絡を排除できるわけではないので、年齢構成など他の要因が効果の主要因であるという懸念を拭えない。

効果を示すには、グループを作成する際に可能な限りランダムに選ぶ、交絡の影響を既存の実験結果から推定して差し引く、投与量を制御して相関をみる。といった作業が必要になる。

というのが統計の基本的考え方。

一方、EM堆肥を実際に農地に施肥して放射線量低減に効果があるかどうか"検証"してみるという番組について、
片瀬久美子女史@kumikokataseは、
https://twitter.com/kumikokatase/status/258842868968476672
https://twitter.com/kumikokatase/status/258892540995067904
で、

EMを使用している農地と、対照としてEMを使用していない農地について、それぞれ複数箇所を測定して、データのバラツキ具合なども考慮して統計的な比較をすれば、どの程度差があるか（ないか）を指摘することはできると思います。

としている。

前述の病院の例に置き換えると、EMを使用している農地を病院Aのグループ、使用していない農地を病院Bのグループ、とみなせる。
複数箇所を測定していく＝患者数を増やせば、それぞれのグループの推定値はより正しくなっていく（個々のデータからくるバラツキは小さくなる）。しかし、グループ間の交絡による影響が排除されるわけではない。
各測定には隣接した農地という重大な共通点があり、例えば雨水からの流出入量、元々の地質の違い、耕作者の掘り起こし深さの違い、近辺の農家の施肥の違いなど、それぞれの測定で共通する交絡因子が容易に予想できる。

想定される交絡を排除した実験を行なって初めて、因果関係＝効果の有無を指摘できるようになる。
統計を使う記事を書くサイエンスライターが、交絡を無視するというのは問題がある。

この人の場合、ダイアリーのエントリ、 http://d.hatena.ne.jp/warbler/20120907/1346997502 をみると、EM批判の文脈ではEM堆肥とカリウムとの交絡を指摘している。
持論の必要に応じて、意図的に無視しているのか、気付いていないだけなのかは文章からはよくわからない。

交絡の排除のないn=1の比較はただのデモンストレーションであって、効果の有無の検証には成り得ない。
https://twitter.com/kikumaco/status/258838747439841281

全国電話帳関連エントリについたコメントへの返答

「情報に詳しい通りすがり」を名乗る方からコメントがあったので少し丁寧語で返信。
http://causeless.seesaa.net/article/296187376.html#comment

"誰でも"云々は自分のエントリに対する指摘かと思いますが、
一般に"誰でも"は、「誰の要求でも許容する」事を指します。例えばフリー雑誌などの、"誰でも"ご自由にお取りくださいは、自分で取りに行く能力がない赤ん坊を対象にしていません。
特にWebでは、アクセス制御がかかっていないリソースは"誰でも"アクセス可能と見なされます。あなたにサーバまで辿り着く能力があるかどうかは関係ありません。

その他、特定人物・団体の虚偽や売名行為の指摘などは全てあなたの憶測と思われますので、根拠を公開の場所で示してください。
根拠が示されていない現状、失礼ながらあなたのコメントは名誉毀損に当たる可能性がある不適切ものであると、判断させて頂きます。

「情報に詳しい通りすがり」さんのIP 182.169.188.229 からの当ブログへのコメントはブロックさせていただきましたので、今後は公開の媒体で根拠を示した上で、トラックバックやTwitterメンションなどで言及リンクをお願いいたします。

なお、誤って別エントリ http://causeless.seesaa.net/article/296089367.html#comment 
に投稿されたらしい同一内容ポストは（全てのコメント確認後）削除しました。

ダウンしたt.coを回避してリンク先を見る方法

twitterの短縮URLを提供しているt.coのドメインが死んでたようで、世界中で問題になっていたようだ。

Webブラウザでtwitterを見ている人は、t.coがダウンしても回避する方法がある。
ブラウザのアドオン・拡張機能のGreaseMonkey(firefox)やTemperMonkey(GoogleChrome)を用いると、javascriptを好きなページに挿入できるのだが、
下記ページの拙作スクリプトをインストールすれば、twitter公式ページのt.coをスキップして直接リンク先を辿れるようになる。
http://userscripts.org/scripts/show/149312

ぜひお試しを！[PR]

Android/iPhoneスマホのroot不要な広告除去法

Androidスマートフォンで広告をブロックしようとすると、root化してadawayのようなhostsファイル変更が必要。そう思っていた時期が僕にもありました。

root/JB化しなくてもドメイン単位の広告ブロックはできないことはない。ただし、制限もいくつかある。

• wifiオンリー。3G回線では広告が見えてしまう
• 個人単位ではブロック対象をカスタマイズできない
• DNSサーバがダウンするとブラウジングが遅くなる

というわけでroot化したくない、まだroot化方法が出回ってない人にお勧めの方法。

方法としては、広告のドメインをブロックしてくれるDNSサーバを使うというシンプルなもの。アプリのインストールも必要なく、Android/iPhoneの標準機能で出来る。

（追記）設定を自動化するAndroidアプリを公開しました。
https://play.google.com/store/apps/details?id=net.usb0.wifiadblock
http://causeless.seesaa.net/article/306520220.html

ひとまず自分で立ててみたDNSを期間限定で公開しておく。
以下、自宅のルータのDHCP設定がどうなっているかわかる人向け説明。

静的IP設定にして
IPアドレス： 元のまま（できればDHCPの割り当て範囲外）
ゲートウェイ： 元のまま
サブネットマスク： 元のまま
プライマリ： (IPを変更しました 最新のアドレスは  https://app.usb0.net/blockdns.txt を参照)
セカンダリ： 8.8.8.8
にして再起動するだけ。

AndroidならWifi Staticなどのアプリで自動化すれば、他のネットワークに切り替えても大丈夫だろう。

今のところ、ブロック対象はadawayのデフォルトリストと、
http://logroid.blogspot.jp/2012/06/adaway-hosts-for-japan.html
およびseesaa関連のいくつかを追加している。我ながら酷い。

一般的なアプリが利用している広告、ユーザー追跡や携帯端末情報送信をブロックできるが、不意に3Gに切り替わった場合はブロックできないため完全に信用することはないよう注意。続きを読む