Tetsu=TaLowの雑記（はてブロ版）

しがない大学教員が琵琶湖のほとりから呟きます

受験生に『セキュリティの研究がしたいのですが』と尋ねられました

こんな仕事をしてるとたまに、受験を考えている学生さんから直接ご連絡を頂くことがあります。本日頂いたのはズバリこんな感じのもの。

セキュリティの研究をしたいのですが、XX大学と立命館大学どちらがいいですか

ちょっとあなた(^^;そんなん私に聞いてXX大学って答えると思う？と思ってしまったのですが…まぁでも客観的にいってもXX大学は、大学院では情報セキュリティに力を入れてますが学部は昔の電気電子系の色合いの濃いカリキュラムでソフトウェア教育が弱く、あまりお勧めできないなぁ…と思ったので、こんな感じで返答しました。

とても残念なことに、日本には学部のレベルでセキュリティをしっかりと教えるカリキュラムを持っている大学は少ないと思います。すぐ思い当たるのは電気通信大学の情報理工学部総合情報学科がセキュリティ情報学コースを持っているくらいでしょうか。大学院はXX大学は情報セキュリティに力を入れていますが、最近は大学院は他大学に移るのも当たり前になってきていますから、大学院進学時に改めて考えてもよいと思います。
それより、セキュリティの前に、情報システムについて深く詳しく学んでおくことが非常に重要であると思います。情報セキュリティは情報システムの技術の本当に細部に至るまで理解していないと、なかなかその脆弱性の理解に至らないからです。この点では、情報科学に特化したカリキュラムを学部に持つ立命館大学の情報理工学部はかなり魅力があると思います。特に、1回生からみっちりプログラミングを教えるカリキュラムは非常に大きな力が付きます。今、ここまでプログラミングを集中して教える大学は珍しくなっていますので、貴重な存在です。私自身、去年立命館大学に移ってきたばかりなのですが、一昨年就職活動をして公募に応募する際に立命館を選んだ理由は、ここが一番セキュリティに向いた、情報システムをしっかりと教える学部教育のカリキュラムを持っていると感じたからでした。是非本学を受けてくださいね。お待ちしています。

もちろんセキュリティについて興味を持ってもらえるのは大変ありがたいですが、まずは地力が必要です。大学での教育では系統立てて情報科学、計算機工学の体系を教えてもらった方がいいでしょう。あとは暗号はやはり系統立てて覚えた方がいいですが、暗号関係は立命館含めどこの大学の学部でも科目くらいはありますから問題ないでしょう。
そのうえで、システムセキュリティやネットワークセキュリティについては自習していくのがいいように思っています。地力がつけばこの分野、自習の方がいいくらいですよね。どうせ変化の早い分野なのですから、大学の講義になる頃には内容も陳腐になっています。それよりは自習したり、勉強会に行ったり、セキュリティキャンプに参加した方がいいと思います。
研究になると大学院ですが、やりたいことを実現するにはどの大学院を選ぶ、というより「どの先生を選ぶ」という要素が大きいように思います。私も選んでもらえるような先生を目指したいものですが。

Windowsノート機で左CtrlとCaps Lockを入れ替えようとしたらハマった件（犯人はSynaptics）

というわけで新年早々、マシンの引っ越しをしていたのですが、久々にハマったのでメモしておきます。

私のような古い人間はAキーの左側にCtrlキーがないと何かと不便なので、新マシンを導入したらまずやることの一つがCaps Lockキーと左Ctrlキーの入れ替えです。世の中にはBIOS設定でこのキー入れ替えが出来る機種もあるらしいのですが（VAIOの一部？）、残念ながら私のはそうではないのでソフト的に解決しています。幸い、WindowsはNT系になってから、キーの入れ替えはレジストリエントリを1つ作るだけでできるようになりました。左CtrlとCaps Lockの入れ替えは

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,03,00,00,00,1d,00,3a,00,3a,00,1d,00,00,00,00,00

でできます（要再起動。.regファイルはここに置いておきましたのでご入用の方は自己責任でどうぞ）。このエントリの意味はgoogle:Scancode Map Ctrl Capsとでもすれば見つかります。このレジストリ変更を補助してくれるツールもいろいろあって、私がよく使っていたのは窓の杜で紹介されていたChange Keyというツールです。
Change Key - 窓の杜ライブラリ
さて本題ですが、いつものように新しいマシン（LIFEBOOK WS1/M）でこのレジストリ設定をしてキーを入れ替えて使い始めたら「Ctrlを押しながら左クリックができない」ことに気づきました。なんだろなと思って調べたら左Ctrl（物理的にはCaps Lock）を押していると、マウスカーソルが動かずマウス関係のイベントが全く発生しなくなるのです。それではと、キーボードクラスドライバの上でフィルタドライバとしてCapsをCtrlに置き替えるツールであるSysinternalsのCtrl2capを試したのですが症状は全く同じ。右Ctrlだと問題ないので、どうやら「ハードウェアキーとしてのCaps Lockが押されているとマウスイベントが発生しなくなる」ということが判明。
なんだこれとfacebookで騒いでいたら後輩がすぐに『なんとなく「キー操作中はタッチパッドを無効にする」みたいな機能がどこかにあってそれが影響してそうな？』とヒントをくれたのでそれを頼りに探したら、原因がわかりました。犯人はSynaptics製タッチパッドのデバイスドライバでした。
Synapticsの最近のタッチパッドには、キータイプ中に誤ってタッチパッドに触ってしまいカーソルが動いたり、果てはタップになってしまったりしないように、SmartSenseという機能がついてます。キーのイベントが発生すると一定期間タッチパッドからのイベントを無視するようにデバイスドライバが作られているようです。しかしこれを素直に実装するとShiftやCtrlなどの一部キーを押しながらのマウス操作（タッチパッド操作）が出来なくなってしまうので、これらのキーに関するイベントを例外処理することが必要になります。どうやらその例外処理がデバドラ内にハードコードされており、それがScancode Mapによるスキャンコード入れ替えより前に行われてしまうので、こんな症状が起きるのだろうと推測しています。確かにレジストリをつらつら見てたらi8042prtドライバの直後に噛んでるフィルタドライバSynTPってのがあるようで、この辺が犯人だろうと予想してます。
で、とりあえずの回避策ですが「SmartSenseをオフにしてしまう」ことで解決することが分かりました。コントロールパネルのマウスのプロパティからSynapticsのデバイス設定を起動。
f:id:tetsutalow:20140106175027p:plain
SmartSenseの設定を開いて…
f:id:tetsutalow:20140106170957p:plain
これをオフにしてしまいます。
f:id:tetsutalow:20140106171019p:plain
これで無事、Caps LockあらためCtrlを押しながらのマウス操作（タッチパッド操作）も出来るようになりました。
ただこのままだと当然、キーボード操作中にタッチパッドに触れてしまうことによる事故は防げないわけで、できればSynapticsになんとか対応して欲しいのですけれど、Scancode Mapを見てくれとお願いするのは可能でしょうか…

(1.9 SynopticsじゃなくてSynapticsと指摘されたので直しました。Synopitcsは別の会社でしたﾁｮｯﾄﾅﾂｶｼｲ(-.-; シナプスのSynapticsですねそりゃそうだ）

新年のメインマシン新調（LIFEBOOK SH90/M or WS1/M簡易レビュー）

新年明けましておめでとうございます。
立命館大学に移って最初の正月を迎えました。おかげさまでなんとか新しい環境にも慣れて参りまして、研究室も徐々に立ち上がってます。昨年配属された3回生が今年卒研を始めるので、彼らを連れて今年は学会などにも顔を出していこうと思っていますので、皆様よろしくお願いいたします。

さて、新年早々久々に記事書く割にはどうでもいい話なのですが、結構長く使ったメインノート機のLet's Note SX1をこの正月休み中に引退させることにしました。一番の理由が、ちょっとキーを1つ壊してしまったこと（キートップを外して掃除するときにちょっと失敗…情けない）。時々画面の広さがもう少し欲しいなと思うこともあった（最近仕事ででかいExcelと格闘することが多くて）のがもう一つの理由。さらに、Haswellを待ってたのでラインナップがそろった時点が買い替え時かと思っていたのもあります。とはいえお気に入りの機種ではあるのでサブマシンとしてまだしばらく使い続ける気ですが。
ということで昨年秋ごろには新機種選定に入っていました。私がメインマシンに求めるのは長年だいたい決まってまして、優先順位順に

  • できるだけ長いバッテリ持続時間（目標は実使用で10時間、学会などでほぼ終日コンセントが確保できない時や、米国へ飛ぶ飛行機の中でコンセントがある席が取れなくても使い続けられること）
  • 大きな主記憶（今なら8GBは最低必要）
  • 広い画面（これから買うなら1920x1080未満は避けたい…）
  • 大容量のHDD（速度より容量重視で500GB以上狙いなのと、何かあったときにHDDだとデータ復活などやりやすいので未だにSSDよりHDDを選びがち）
  • アナログVGAの直接出力があること（変換アダプターとか持ち歩くのが面倒なので）
  • バッテリが取り外し交換可能なこと（酷使するので劣化が早く退役前に数度バッテリ買い替えることがある）
  • 可能ならHDDの換装がしやすいこと（容量が足りなくなった時だけじゃなくて、SMARTで見てエラーが増えてきたら予防保守的に交換しているので）
  • 可能ならフロントカメラとマイクあり（最近Skypeなどの使用頻度すごく高いので）
  • 出来るだけ国内メーカー（ノート機くらいしかこの国は戦えてないところ、最近それも危ういので応援のつもりで）
  • 重量は2kg以下ならまぁいいや
  • 光学ドライブついてると少しうれしいかな（DVDでいい、BDはまだ要らない）
  • 鞄にギュウギュウ詰め込んでも大丈夫なくらい頑丈だといいな

という感じ。この条件によくマッチするのがやはりLet's Noteなので、最近はSシリーズやJシリーズ、SXシリーズを買って過ごしてきました（Jシリーズは特に気に入ってたのですが最近出なくなったのは残念ですね…）が、SXシリーズがなかなか解像度を上げてくれないのと、AXも魅力的だったんですがちょっと高すぎると感じて、ここ5年以上お世話になったLet's Noteにサヨナラして久々に他のシリーズにすることにしました。VAIO Duo 13やPrp 13も魅力的でだいぶ迷ったのですが、店頭で見てその剛性と超高解像なディスプレイに魅力を感じて選んだのが富士通のLIFEBOOK SH90/M。結果的に店頭モデルではなくWeb通販のモデルにしたので、型番が変わってLIFEBOOK WS1/Mです（なぜ型番を変えるんでしょう…ややこしい）。CPUをCore i7-4500Uに、メモリを10GB、HDDを1TBにして、ついでに予備のバッテリパック(L)を買っても合計193,670円。この内容にしてはまぁ安いんじゃないでしょうか。Let's NOTEにする前はずっとFMV LOOX TやLOOX Rをシリーズ買いしてた時期もあって(サポート記録調べたら合わせて2002年からほぼ毎年、6台も買ってました！)、富士通にはなじみがあります。
実は注文したのは11月6日だったのですが、届いたのが11月20日。その後も忙しくてなかなかマシン移行のチャンスがないまま1か月以上経ってしまいましたが、冬休みに意を決して環境の移行を開始しました。
というわけで、まだ使い始めたばかりなのですが簡単にレビューを。本機種は上記の条件を全て満たすという意味では大変満足しています。なんといっても画面が広い！広すぎて細かいので拡大を適当にしないといけませんが、PDFを見るときなどは大変見やすく助かります。加えてよいなぁと思ったのはとにかく剛性があるボディで、たいへん安心感があります。キーボードも、少しストロークが浅いかなと思いますが慣れれば大丈夫。SX1に比べると横幅に余裕があるのでキーピッチが変則になってないのはいいですね。
ただ、あえて難点を挙げると以下のことが気になりました。

  • バッテリが思ったより持ちません。私の実使用だと省電力モードにしても6～7時間くらいという印象。もちろんJEITA測定法は現実とかけなはれているのは分かってますけど、今までのLet's Noteに比べると、公称16時間のSX1が私の実使用で8時間十分いけたのに、なぜ公称21時間のWS/1がそれより早くバッテリーへたって来るの？という感じです。何が電池を食っているのか調べて最適化していこうとしていますが…。なおバッテリーがあまり持たないのはPC Watchのレビューでも指摘されていたところ。ただ、バッテリー交換可能*1なので、予備バッテリー持ち歩けば問題なく使えそうです。光学ドライブ外して補助バッテリーにすることも考えましたが、あまり容量が増えないので今回は避けました（そういや、かつてLOOX Tでは光学ドライブを補助バッテリーと交換して使ってましたが）。
  • 細かいことですがタッチパネルなので、ディスプレイとベゼルの間に段差がありません。このため、プライバシーフィルターをシールで張り付けるしかなく、着脱式にできませんでした。私は新幹線などでもずっと仕事してるのでプライバシーフィルターは必須なのですが、他の人にプレゼンなどする際にはよく取り外します。それができないのが少し残念。
  • 私はタッチパッドを小刻みに擦るようにして使う癖があって、そのためたびたびカーソル移動するつもりなのに小刻みすぎてタップと勘違いされてしまうので、タップ機能はオフにしてクリックを多用するのですが、WS/1のタッチパッドのクリックはかなり固めです。クリック時の音も大きく、キー打鍵音が小さいだけに目立ちます。会議中にクリックするのが憚られる感じ（まだやってませんが）。まぁせっかくのタッチパネルモデルですし、そういう時は画面タッチで逃れたらいいのかもしれませんし、この際訓練してタップ機能を使えるようにしたらいいのかもしれませんが…
  • オンボードのメモリが2GBってのは大変残念で、ここは頑張って4GBにして欲しかったです。そうすれば12GBまで拡張できたのに。まぁ10GBでも不足というわけではないですが、HDD使用だと大きければ大きいほどあり難いので。

もしこの機種を検討されてる方がいらっしゃったらご参考にどうぞ。

*1:但しホットスワップはできません。ACアダプタを繫いでいてもバッテリーを抜くと電源が切れるし、デフォルトでは電源ボタンを押してもハイバネーションしない（スリープするだけ）なのでご注意を。私もスリープ状態でバッテリ交換して失敗しました…

政府のオープンデータガイドラインに対してパブコメ提出してみました

ちょっとバズってしまったこのまとめ…
公務員が公開するネ申Excelが日本の生産性を落としている話 - Togetter
バズってしまったのでその責任取らなきゃなぁ（笑）と思って、霞ヶ関界隈でコソコソ活動していたのですが、なかなか出口が見えないでいたところ、内閣官房のIT戦略本部からこんなものが飛び出してきました。
「電子行政オープンデータ推進のためのロードマップ（案）」及び「二次利用の促進のための府省のデータ公開に関する基本的考え方（ガイドライン）（案）」に関する パブリックコメントの募集について
これは…なかなか頑張ってるけど率直な感想として…意欲は買えるけど、正直求めてるものがちょっと一足飛び過ぎるんじゃないかと思いました。オープンデータ戦略としてはまずは公開のインセンティブを高めることが重要です。公開データの再利用性も大切ですが、「機械可読形式」という言葉を繰り返したところで担当官に正確に理解できる気がしません。おそらく作業を直接担当することになるであろう係長級から平官の人たちの一般的ITリテラシでは、このガイドラインのココロを理解できないまま見よう見まねでやってしまい、かえって混乱を増すんじゃないかとちょっと心配になりました。
なので、ちょっとエイヤとパブコメ意見を提出しておきました。ここに同じものを貼り付けておきます。

ここに来てオープンデータについて推進しておられること、大変心強く思います。
一方で本ロードマップ、ガイドラインについていくつか気になる点がありますのでコメント差し上げます。

ロードマップについて

２－（１）－丸２　具体的な取組　について
『二次利用可能なデータ公開を促進するため、公開データの二次利用により生じた損害に関する免責についても明確にすることとする。』この言葉で免責される主体が明確ではありません。文脈から免責されるのはデータ公開主体、つまり省庁側・国側であると思われます（ガイドライン側にはそれが明記されています）が、これをロードマップでも明確に書いて頂けないでしょうか。省庁側担当者側のオープンデータへの障害の一つは、やはりデータ公開によって生じた損害が国の責任に問われることにより本人の責任につながる、という構造のように思います。その免責を強く打ち出すべきかと思います。

２－（２）機械判読に適したデータ形式での公開の拡大　について
この項目を受けてガイドラインにおいて「機械判読に適したデータ形式」での公開という言葉が強く出すぎている印象を受けました。これが目立ちすぎますと、機械判読に適したデータ形式になってない・変換に手間がかかることを理由にデータ公開が進まないという逆の副作用が懸念されますし、高いエンドユーザコンピューティング能力を担当者に求めると、結局データ公開の作業をアウトソースするなどの原因となりコストが増します。大事なことは2次利用の拡大であり、機械判読に適したデータ形式での公開の拡大は2次利用の拡大のための手段に過ぎないと考えます。例えばこの項目を２－（１）の項目の下に置くか、順番をさらに後方にもっていくなど、優先順位を下げた印象を与える表現にして頂いた方がよいのではないかと思います。

２－（４）公開データの拡大　について
公開データの拡大には各省庁担当者の努力が求められるところですが、業務評価に繋がらなければその努力に見合うインセンティブを与えられないと考えます。データ公開が結果として二次被害的なことにつながり非難され責任に問われることが上記２－（１）の免責によって除外されても、やはり十分な担当者のインセンティブとはなっていないと考えられます。「担当者の業務評価に結びつけることにより、データ公開のインセンティブとする」ことを明記してはどうでしょうか。また、データ公開やその機械可読形式への変換に必要な担当者のＩＣＴリテラシ向上策も書き込むことはできないでしょうか。

ガイドラインについて

ガイドラインの書き方として、二次利用という言葉よりも機械判別可能形式という言葉が強く出過ぎているように思われます。機械判別可能形式がどのような形式であるかということが判断できるほどのＩＣＴリテラシが省庁担当者に十分あればよいのですが現状はそのレベルにはなく（そもそもそのレベルにあれば現在のような状況は生まれていません）、このガイドラインを正確に読み取ることが出来る担当者がどの程度いるのか不安があります。
そこで提案ですが、本ガイドラインは、以下のことを強く打ち出した書き方に出来ないでしょうか。
１．重要なことは二次利用であることを強く書く。そのことを強く印象づけるため、ケーススタディの前に「二次利用例」を入れる。
２．「機械判別形式にすることを強制」するガイドラインから、「データ形式と表現形式は別物であり、本来は基礎データがあってそれを自己再利用することで見やすい形式に変換するものである」という印象を強く与えるケーススタディにする。現在は1つのExcel表をひたすら機械判別に向いた形式に変換する結果、単に「見栄えを悪くする」方向に変換するように読めてしまうため印象が悪い。これを、別のシートを作ってそこに機械判別に適した表（生データシート）を作った上で、そのデータからの参照やExcelの機能等を用いて元と同じ「見栄えのする」表（印刷用シート）を作り出すようなケーススタディにする。これにより、担当者自らがデータの二次利用を行うことになり、そのベネフィットを感じられるようになるはずである。

以上、意見提出します。

SSL/TLSでBEASTを恐れてRC4を優先するのは危ない

前職のお仕事で電子政府推奨暗号リストの改定作業を行う暗号技術検討会の事務局をやってたのですが、それ関係の話。3/1付けで電子政府推奨暗号リストあらためCRYPTREC暗号リストが公表されたのですが…

電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）に対する意見募集の結果

 今回の改定では、電子政府で広く使われているがすでに危殆化が始まっているものを「運用監視暗号リスト」にするということが行われたのですが、今回その扱いにされた暗号のうち代表的なものがストリーム暗号RC4です。この件、もう少し大きな話題になってもいいと思うのですが…

…話題にならないのでちょっと解説。

RC4はストリーム暗号としては大変広く使われていますが、同時にいろんな脆弱性があることでも知られてきました。今回のCRYPTRECによる調査では「同一の平文を異なる（多数の）暗号鍵で暗号化した場合平文が復元できてしまう」という問題が明らかになり、運用監視暗号リスト行きの決め手の一つとなりました。このことを示す技術報告書はすでに公開されています。

五十部孝典「ストリーム暗号RC4の安全性評価」(PDF)

これ、RC4の危殆化が一段と進んだことを表してて、危険な兆候だと思っております…なのに、そのことが話題にならないのは、その危機感が暗号業界以外で理解されにくいから、なんでしょうか。

RC4はWEPやSSL/TLSで広く使われてますが、WEPが脆弱であることが広く知られているのに比べ、SSL/TLSでのRC4はそれほど恐れられてきませんでした。SSL/TLSでは多くの暗号が選べますが、メジャーなのはRC4_128_SHAとかAES_128_CBC_SHAあたりでしょうか。通常の発想では、従来より脆弱性が指摘されているRC4よりはAESを優先にするべきとなるところですが、最近はむしろSSL/TLSではRC4を優先すべきという論調が増えていました。というのは、ここ1～2年のうちにSSL/TLSにおいてAESを含むブロック暗号をCBCモードで使っている際に有効なBEAST攻撃やLucky13攻撃などが報告されてきており、その対策としてRC4への移行が促されてきたからです。

MS12-006 SSL/TLS の脆弱性のちょっと詳しい解説(Microsoft TechNet Blog: 日本のセキュリティチームによるBEAST攻撃の解説)

Nadhem J. AlFardan and Kenneth G. Paterson: Lucky Thirteen: Breaking the TLS and DTLS Record Protocols (PDF)(Lucky13攻撃の原著論文：対処としてRC4の利用について言及されている)

実際、GoogleやFacebook、TwitterなどがRC4を優先にしているのもそういう事情があるようです（まぁ単純に負荷が低いからと言う事情もありそうですが、昨今はAES-NIが使えるCPUが増えてますからAESでも変わらないかむしろ負荷は下がるように思います）。

しかし今回、RC4の危殆化が明らかになったことでまた話が変わってきました。BEAST攻撃やLucky13攻撃は暗号学的には目新しいところはないのですが、技術の組み合わせの妙によって実際の攻撃が可能であることを示して見せたあたりに目新しさがある、というのが私の理解です。一方、RC4に関しては本体の暗号学的な脆弱性の進展がありましたので、ここにBEASTあたりで使われていた各種技法を取り入れることによって、かなりの現実味を持って平文を回復する攻撃を作り上げることができそうな状況にあると見ています。SSL/TLSにおける平文の回復で一番厄介なのはセッション等に使われているCookieを外部から読まれることで、そこまで可能になれば脅威はかなり大きなものとなります。

なので、少なくともSSL/TLSにおいてBEASTを恐れてRC4を優先にするのは脅威を軽減できていないという意味でかなりナンセンスな状況ですし、RC4に対する攻撃の脅威がBEASTを一気に飛び越しかねないと思います。なので、そうなってしまう前にBEASTをはじめとする各種攻撃の回避へのWorkaroundとしてRC4を推奨する記述を消して回った方がいいと思うんですけど、どうしたらいいんでしょうね？？私も言えるところには言っていこうと思ってますけど、私一人では限界があるので、この話を理解して頂いて賛同頂いた方には是非、ご協力をお願いしたいのですが…

参考：ＣＢＣモードの現在 - Togetter

ついで。以下の記事はAlFardan, Bernstein, Paterson, Poettering and Schuldtの成果のように書いてますけど…

A Few Thoughts on Cryptographic Engineering: Attack of the week: RC4 is kind of broken in TLS

 こちらの、五十部-渡邉-大東-森井の方が早いです。

Security of RC4 Stream Cipher

転職のご挨拶

一日遅れになってしまいましたが、ご報告です。4月1日付けで立命館大学に採用していただき情報理工学部情報システム学科に教授として着任しました。

既に申し上げたとおり京大から総務省に出向していたわけですが、ちょっと我が儘をお願いしまして任期（といってもはっきりとはしていなかったのですが一応2年程度）の満了前に辞めさせて頂きまして立命に移ることにしました。そのため大変面倒な事務作業が発生してしまい大変ご迷惑をおかけしました。お骨折り頂いた各位に御礼申し上げます。

昨年、立命館の情報理工学部から4学科合わせて6人もの教授公募人事がでまして、求職中の私としては絶好のチャンスでした。昨今の情報系教授人事は、私と同世代の研究者が教授適齢期であることと、このごろの総合電機メーカーの不振で企業研究者の大学教員への転身が増えていることから倍率は本当に高くなってしまい、ある程度名の通った大学だとすぐに50倍100倍となってしまう（首都圏では200倍とかいう話もきいて目眩しました）状況でしたので、一気に複数のポストが公募されて倍率が下がると思われるこの機会を逃したくなかったのです。実際読みは当たったようで、なんとかうまく滑り込むことが出来ました。拾って頂いて感謝しております。

立命館大学では情報システムのセキュリティやインターネットセキュリティを中心に、コンテンツ管理とかデジタルフォレンジックとかいうあたりを掲げて研究していきたいと思ってます。情報システム学科というところは今時めずらしく、比較的基礎の情報科学、情報システム学をしっかり教えるところです。こういうカリキュラムで育つ学生は計算機の基本原理に詳しくなるはずです。そういう中から、ソフトウェア脆弱性といったようなセキュリティの根幹技術の話をきちんと理解できた上で、さらに幅広い知識を持つセキュリティ技術者をどのように育てるか、ということが私の一つのテーマになるのだろうと思います。

これまで京大でお世話になった皆様に感謝申し上げるとともに、今後ともご指導ご鞭撻を賜りますようよろしくお願い申し上げます。

震災から2年

あの日から2年経ちました。改めて亡くなられた方のご冥福をお祈りし、今も不自由な生活をされている多くの方々に心からお見舞いを申し上げたいと思います。

2年前のTwilogみてみると…なんか揺れた直後に津波を心配し、友人の身を一通り案じた後は、意識がひたすら原発にいってたなぁと。

上原 哲太郎(@tetsutalow)/2011年03月11日 - Twilog

私は原発の専門家ではないけど多分普通の人よりは原発の構造が理解できていたと思いますので、正確に状況を想像出来ていたと思います。2号機の圧力抑制室破損の報せには本当に涙を流して泣きました。事態は私が予想していた中でも最悪に近いシナリオで進みましたが、それでもなんとか原発の冷却状態を取り戻せたことは不幸中の幸いですし、残る山積する問題に真剣に取り組まれている人たちには本当に頭が下がる思いです。

あの日から数日経った頃には、私の頭の中にはこの国についてもっと辛いシナリオばかり渦巻いていました。端的には原発の風評被害で農水産物から工業製品に至るまで輸出が大打撃を受けたり、電力不足が深刻化してこの国の経済が痛み、一方復興と原発廃炉処理の負担が増して疲弊していくようなシナリオです。とはいえ、知恵を集めれば解決は少しは回避されるのではないかと思ってました。

ここでは原発のことばかり言ってますが、あらゆる問題について大学人の持つ知恵を集めることで解決が早まるのではないかと、そんなことを考えていました。なので、提案を受けてからずっと迷っていた霞ヶ関への出向に関して覚悟を決めました。私にも何か出来ることがあるんじゃないかと。


転職（出向）しました - 2011-10-03 Tetsu=TaLowの雑記

で、総務省に来てから1年半経ちました｡

結果的に言うと私、正直なところ全く力が足りませんでした｡残念無念です。

入省直後、一番やりたかったこと＝震災復興に直接役立つ仕事には手が届いていないことははっきりしていました。まぁ専門家ではないのだから仕方がないかなとそれは早々に諦めて、ならば、代わりに与えられたことで自分の知見を生かして精一杯やればいいのかと思ったんですが…所詮官僚としてはポンコツなわけで、何でも出来るわけじゃありません。当初与えられた通信の標準化（しかも「セキュリティ関係は除く」）の仕事はどうにも専門から遠く力が出ません。すぐに「もう少し私の力が生きる部署に異動させてくれませんか」と波風を起こす要求に出てみました（前例がないことですから、当時、うちの組織は途方に暮れたでしょうね…）

幸い、ほぼ1年かけていろいろな方のご努力で、この状況の中で、私がこの組織の中で過ごす時間がより生きるよう、セキュリティ対策室への併任をかけてもらえました。そのおかげで特に電子政府推奨暗号の改定という難しい仕事の大詰めの部分に関われたことは自分でもよかったし、多少なりとも国のお役に立てたのではないかと自負しています。他にもいくつか興味深い仕事をさせていただけました。

ただ、そうして仕事を続けるうち、山積する重要課題を解決するために、あまりにも遠回りしているのではないかという思いも強くなりました。私個人も個々やっていることは決して無駄じゃないと思ってるし、霞ヶ関の住人の多くは自分の担当に真剣に取り組んでおられるのですが、そのままでいいとは思えませんでした。国として解決すべき問題の優先順位がある中で、予算や人的リソースの配分のバランスが必ずしもそれに合致しているように見えないのです。しかし私のような下っ端ではデシジョンメークの場にあまりに遠く、そのバランスを修正できる機会はありません。さりとて、自分自身で動いて重要課題（と私が感じている）仕事をしている組織内の他の部署の人たちに手伝いに行くのも、組織の仕組み上どうしても限界があります。

結局のところ、霞ヶ関の中で私が出来ることが大変限られていました。それは私自身の力不足もあるでしょうし、やり方のまずさもあるでしょうし…私にとっていいことがなかったわけでもなく、またお役に立てる機会が皆無だったとは言わないけれど、この1年半は総括すると私の中では「失敗」でした。選択ミスです。

ということで、ちょっと我が儘を通していただくことにしまして、少し早めに、今月をもって総務省を退職することにしています。立つ鳥跡を濁さずと言いますが、結局のところいろいろ組織を引っかき回してしまっただけに終わる気がしていて、大変申し訳ない思いがします。ホントにさまざまな制限のある中、私の我が儘を聞いて汗をかいていただいた皆さんに感謝します。そして申し訳ありませんでした。今後は別の形で、より私の知識や能力が生きやすい方法で、お役に立てる機会がないか探ってみようと思います。その機会があればそこでご恩をお返しいたしますので、よろしくお願い申し上げます。

なお、今後の身の振り方についてはまた改めてお知らせします。