JAVA 警察・JAVA 奉行・公開鍵暗号警察

「はてな」で医療機器関係のエントリ書いてたら、なぜか限定公開になってしまった。
私よりもっと過激なこと書いているブロガーなんて山ほどいると思うのだが、なんでだ?
こういうことされると、さすがに、信用できなくなる。こちらのサイトの管理人さんのご厚意で、転載させてもたうことになった。感謝。

BMI
その他数名(笑)寄稿




Java 警察

最近はソフト方面はさっぱりなのだが、Java にまつわる情報の錯綜は視野には入れていた。
Java の主要なステークホルダーも、さすがにこれはまずいと思ったのか、「正しい」情報発信と怪情報是正のためにどこかで Java警察 なる自警団的な組織をつくったとかつくらなかったとか。
でも、経験的にいって、こういう管理の仕方って上手くいかないと思うよ。
別に集中管理が絶対とは思っていないが、利害関係の甘さはそのまま管理の質の甘さにつながるのが世の常。破滅への道は善意で埋めつくされているとよくいうではないか。(さすがに、今、Java にいきなり破滅してもらっては困るわけだが)
実際のコミッターよりもインフルエンサー気取りの連中に変な称号与えちゃってる節があるのはどうかなーと思う。
だから、Java警察というより Java奉行みたいな言い方の方がいいんじゃない?と仲間内では盛り上がっていた。
この場合の『奉行』ってのは「鍋奉行」的な意味合いっす。
別にコミュニティ全体を馬鹿にしているわけではなく、こういうやり方だとどうしても滑稽に見える人が出てくるからだ。

ところで、私は、仕事としてはかつてサーバーサイドの Javaプロジェクトにかかわっていたことがある。たぶん、一番、Java が重宝がられていたとき。
その当時は、こういう状況になるとは誰も予想していなかったと思う。

Java が栄華を極めていた頃の印象が強いせいなのか、「Java の公的な仕様に従っていれば、望む機能はすべて実現できる」と考えている人が意外に多くて、びっくりした。
で、こういう人たちが Java 警察っぽくなっている状況がなんかイヤっぽい。

最近の Java にはあてはまらないかもしれないが、私が経験した限り、使うのが難しいと感じた局面を挙げると・・・

 ・TimerTask クラスを用いるとき

・通信のタイムアウトを取り扱うとき

など。
サーバーは堅牢なマシンで常時稼働しておけばいいかもしれないが、クライアントはそういうわけにもいかず、例えば、クライアントPC がスリープ状態に陥った時、確立した通信路は当然破棄されているわけだが、このときの復帰動作は JVM からの戻り値(expired であったり null であったり...)によって何らかの工夫が必要で、これが意外に面倒だった記憶がある。
TimerTask にしても然り。
LAN にぶら下がっているクライアントがせいぜい十数台という程度なら、ここまで考える必要はないのかもしれないが(何食わぬ顔でクライアントを再起動するとかw)、不特定多数のクライアントと通信させなければいけないときなど、そういうわけにはいかないでしょう>新人 (^^)

最後、リアルでの不満がぽろっと出でしまったが、最初のお題はこんな感じにしてみました(笑)。


 BMI


(追記)その後、Java 信者みたいなのは息してない感じになっている。
最近(2021冬)だと、ロガーとしてよく使われているライブラリの log4j に脆弱性が見つかった。

「やばすぎる」 Javaライブラリ「Log4j」にゼロデイ脆弱性、
任意のリモートコードを実行可能
iCloudやSteam、Minecraftなど広範囲のJava製品に影響か


当たり前だが、どんな言語でも実用レベルでバグのない完全な動作環境を提供することはできない。
なぜ「Java は絶対」みたいな雰囲気を無理してまで作ろうとしたのか理解に苦しむ。

(追記2)現在(2024春)だと Java はサーバーサイドでは生き延びれそうではある。
ただ、デスクトップアプリはオワコンだろう。
今では各種 JDK が公開されるようになったが、主要 OS への対応、特に MacOS (GUI)への対応はその SDK 開発陣のポリシーによる。
まったく配慮していないものもあれば、Arm Mac に対応しているものもある。
この状態で新規に Java デスクトップアプリのプロジェクトを起こすのはかなり無理がある。


公開鍵暗号警察

(追記3)IT 関係者の一部にいまだに「XX 警察」を名乗りたい輩がいるようだ。けっこうな人が Java 警察の一件で懲りて、おいそれと XX 警察とは名乗ってないのになあ・・・。びっくりしたので書き留めておこう。
具体的にいうと X の @angel_p_57 とかいう人。
自称「公開鍵暗号警察」。
彼によれば、巷に溢れている公開鍵暗号に関する説明はほとんど間違っているんだそうだ。例えば、この問題、


ワイも a,b,d かなあと思うし、出題者が想定していた解答も a,b,d なのだが、彼によれば正解は a,b のみなんだそうだ。
署名のときは、より一般的な署名鍵・検証鍵という言い方が適当だから・・・云々というのがその理由らしい。
ワイにしてもこの分野は通り一遍の理解しか持っていない。でもさ、その(彼からすれば)間違った理解でゴリゴリ実用的なコード書いている人がいて、そのおかげで正しく動作するソフトが流通しているという現実はしっかりと認識しているつもりだ。
本人は「私の指摘は重箱つつきではない」と主張しているようだが、彼のタームを採用している現場寄りの人はおらず、現実的には彼の説はほとんど何の影響も与えていない。
そんなに自説に自信にあるなら、正しくてスーパーな JPKI や HPKI のユーティリティソフトでも作って公開したらいいと思うんだが、実際にやっていることは Qiita の記事執筆程度。
しかし、この調子で山形浩生さんに絡もうとするって度胸あるよね。
ちなみに医療情報関係者からは、まったく相手にされていない。
理由は簡単で、言葉の定義にうるさい割に糖尿病の1類や2類とかという明らかに一般的ではないターム使ってたから。
「その手の人」がいくら基本事項間違えても指摘しないでおく医クラの優しさ(防衛本能の高さ?)よ。

(追記3−1)私はあまり詳しい知識はないので参戦していないのですが、追記3の人の批判(非難ではない)がなぜかこちらで始まっています。人をイラつかせる天賦の才があるんでしょうね。


紹介しているだけでは面白くもなんともないので公開鍵暗号が関係したプロジェクトに関してあれこれ書いてみたい。
アウトプットも一応はある。
このサイトで紹介されている HPKI 関係のツールの作成をお手伝いした。もっとも商用ではなく内輪で使うような実験的なものだが。


HPKI は一般の方に馴染みが薄いかと思うが、Healthcare Public Key Infrastructure の頭文字を取ったものでマイナンバーカードの医療分野版だと思ってもらってもそう大きな間違いはない。
HPKI は公開鍵暗号をいたるところで使うが、では angel_p_57 の主張が何かの役に立ったかというとそんなことは一切なかった。
というか、彼の独自解釈はほとんど言葉遊びというべきものだということがよくわかったし、実装実務レベルではほとんど役に立たず、頭に引っかかっているとむしろ害悪ですらあった。

これは私だけが言っているわけではなく、このページで angel_p_57 に絡まれたある開発者も以下のように吐露している。

最後に、今回Twitterでお話させてもらって思ったのだが、セキュリティの評価をするときにユースケースや背景にある技術をすり合わせずに話すと、原理的な話だけしかできなくて、攻撃容易性や危険度について正しい評価がされないなぁと感じたので、議論のベースをすり合わせてから話すのちゃんとやらないとなぁと思った。

表現は抑えめにしているが、これはエンジニア的に意訳するなら

(意訳)こいつと話していると原理的な話に終始して、実装レベルの議論にならない。
攻撃容易性や危険度についての評価が欲しいところなんだが。以降は相手を選ぶなりして気をつけよう。

でしょう。私がこれ言われたら正直凹みますね。

話が脱線した。



まず HPKI で使われる公開鍵暗号の概念的理解だが、以下の例示が最もわかりやすかった。

秘密鍵(77, 43)と公開鍵(77, 7)を持っている自己愛的で性癖歪み気味のタレントAさんがいます。
Aさんから「結婚しないか」と口説かれている元局アナBさんはAさんに 48 という数字(アスキーコードで 0 。ここではNoという意味)を手紙で送りたいと思っています。
ですが、郵便局に文春に贈賄された悪い人がいて中身を開封してこっそり読んでしまいます。
そこでBさんは、Aさんの家の屋上に設置された「コスメティック 77-7」看板を見て48^7 mod 77=20を計算して送りました。
郵便局の悪い人は「そうかー、20かー、制御文字じゃん。B のワープロ壊れてやんの」といい気になってます。間違った情報をつかまされているのに・・・。
手紙を受け取ったAさんは 20^43 mod 77=48 を計算し、「お、Bさんの真意は 48 (No)か。性癖に素直になった方がいいのかな」 肩を落としながらも正しくBさんの意図を汲み取ることができました。
めでためでたし。


(この話のバリエーションはいくつかあるのだが、オリジナルはここ

そもそも公開鍵暗号とはなんぞやという定義が抜けているが、常識的なものでかまわないでしょう。
困ったちゃんがこだわる「暗号化」だのの定義もここでは「べき乗計算と mod 演算」という具体的な計算に置き換わっている。
ややこしい「鍵交換方式」なども「看板に書かれた公開鍵の目視」で果たしている(笑)

理解を妨げる装飾物を剥ぎ取っていくのが好きな人たちの考えたケースだから、上の例に至っては舞台は「ネット」ですらない。

もちろん、暗号化や復号化に対応する数学的操作は「べき乗と mod 演算」に限定しているわけだから、これが RSA を前提にしたものだという制約はつく。ただ、数学的操作を無視した議論に実用的な意味はほとんどの場合でないということをこの人たちはよく知っている。楕円曲線暗号を採用した公開鍵暗号を理解したければ、同じような例を捻り出せばいいくらいに思っているでしょう。
HPKI では暗号方式として RSA を採用しているので実務的には何ら問題にならない。

また、このようなコンパクトにまとまった理解をしておくと、実装の時に迷わなくて済む。
このプロジェクトの目標の一つは、電子処方箋などの文書を基に作られたメッセージの署名値を求めることだが、具体的な計算は HPKI カードに中に収められたアプリが「秘密鍵を用いたべき乗と mod 演算」ことで行う。実際には、IC カードリーダーを介してメッセージと命令をカード内に搭載されているアプリに届ければよく、このプロセスの実態はこのような「アプリによる計算」としか呼びようがないものだ。
こういった状況に対して「署名を秘密鍵による暗号化というのは間違いだ」(= angel_p_57 の主張)と主張したところで何になるだろうか。
コーディングやデバッグの時に注意を払うのは「計算が正しく行われているか?」であって、それを「暗号化」と呼ぼうが「署名」と呼ぼうが大した意味は持たない。アプリからの返値は署名値のかけらとでもいうべきもので、これ自体は「署名値」ではないという事情もある。
彼の説明を「頭に引っかかっているとむしろ害悪ですらあった」と書いたのはこういった理由による。

なお、HPKI で提供されるサービスは当初は電子処方箋くらいしか目立ったものはなかったが、現在では診療情報提供書、いわゆる「紹介状」も電子的にやり取りしようというところまで拡大している。
処方箋にしろ紹介状にしろ、医師が書くもので途中改ざんはあってはならないものだ。
その電子的フォーマットも文書によって異なり、当然、署名値を求めるプロセスも文書によって変わる。臨機応変に対応する必要があり、ここでもまた angel_p_57 的な理解は邪魔にしかならなかったことを付け加えておく。

この経験から得られるものは何だろう?

HPKI の技術的な核になる公開鍵暗号だが、仕様に基づくコーディングやその経験を踏まえての提案には、軽めの直感的理解の方が役に立つとは言えそうだ。
現在は、RSA を採用しているが将来的には別のものになることは十分ありえる。実際、細かな仕様など日に日に変わっていた。
中途半端に一般的な理解は要らない。
RSA ではこう、楕円曲線暗号ではここが変わったと把握する方が臨機応変に対応できる。
繰り返すが、言葉遊びのようなものは要らない。

簡単な事例での概念の把握、実務に役にたつ理解の仕方、スピーディーな試行錯誤・・・そういったものが、実装では重視されるべきだと思うが、この真逆にいるのが「XX 警察」的な特性であり、このような即興性が必要とされるプロジェクトではとりわけ忌避すべきものだ。
実務家と同じ目線に立てず、何の役に立つかもわからない戯言を捲し立てる輩が現場を仕切り始めたら、それはそのプロジェクトが炎上する予兆だからだ。



コメント