Home
2025年
2024年
2023年
2022年
2021年
2020年

12月31日 開発中のアイドル認証アプリが世界にヒットする理由

年内にリリースすることを目標としてきましたが、あと少し待ってください。 そして産業スパイによる妨害を止めるように国民の皆様、よろしくお願いします。 IdleAuth認証アプリについては僕のSNSの最近の投稿で確認して欲しいのですが、 一言でいえば古いPCを「Google認証システム」のようなものにしてインターネットを安全にしてくれます。 PC 1台を使い切って認証デバイスにするのですが、多数の認証鍵を1つのPCで操作できるので便利です。 これが世界にヒットする理由の一つを、急ぎ解説したいと思います。

まだ開発中のものですが実行ファイルのサイズが、たったの35KB、最終的に40KB程度になる見通しです。 MFCをスタティックリンクにすると164KBですが、両方のバージョンをリリースする予定です。

本人認証のための秘密鍵を扱うソフトウェアなのでウィルスがついていないかなどを心配される方は、 非常に多いと思いますが40KBであればリバースエンジニアリングによって安全を確認することが容易です。 1人が確認できればファイルのハッシュ値によって安全を全世界の人と共有ができます。 IdleAuth認証アプリはクローズドですがオープンソースよりも安全性の確認が容易かもしれない。 オープンソースではコンパイラが安全か?という問題があるので。

どうして非常に小さい実行ファイルなのかといえば、認証アプリに実装されている、ほとんどの暗号機能は Microsoft Windowsの標準の暗号モジュールを使うからです。
Microsoft Enhanced Cryptographic Provider v1.0

これは米国ではもちろん、銀行などでも馴染みのある暗号モジュールでWindowsが信用できる多くの人が、 安心できると思います。

リリースまで、もう少しお待ちください。



11月25日 PCのスリープ機能を狙ったサイバー攻撃が連続して発生

本日、自宅のWin11のメインPCに続いてLinuxサブPCもサイバー攻撃を受けました。推定、産業スパイによるもの。 どちらのサイバー攻撃もPCのスリープ機能を狙ったもの。 LinuxサブPCは起動不能に。昨日、Firefoxに毎月5ドルの寄付を開始したばかりだった。 とりあえずスリープ・アタック(仮)という攻撃名にしておきます。 サブPCはRed Hat Enterprise Linux 9.4ですが、今月中旬に9.5がリリースされ自動更新されていました。 しかしシングルユーザーモードからのshutdownで9.4でブートしても現象は変わらず。 9.5のアップデート不具合ではなくてサイバー攻撃と推定。 攻撃者は、必ずといっていいほど、あたかもアップデート不具合で起きたように見せかけることが多いようです。覚えておきましょう。 本物の攻撃者であれば、このスリープアタック(仮)で起動不能にすると攻撃方法を悟られてしまうので、 産業スパイによる模擬サイバー攻撃だろうと思われます。

昼食などでPCをスリープにして席をはずした時、攻撃者はインターネットからリモートでスリープを解除して、 ブラウザなどを勝手に操作することが可能なようです。 問題なのはリモートでスリープを解除できない設定にしても攻撃できること。 何故ならウィルスがスリープボタンの動作を「ディスプレイの電源を切る」に勝手にしても、攻撃が可能な点。 ただし今回の自宅PCのケースは、設定の変更ではなくて、いずれもOSの改ざんだった。

スリープして席をはずしたときに、侵入して現行のマイナンバーカードの署名を盗めるようなウィルスを仕込めば、かなり大きな被害をだすことができるでしょう。 (グーグルもモジラも大量リストラをしているので、こういった仕込みができるエンジニアが大量にフリーになっていることが気がかり)

非常に凶悪なサイバー攻撃なので、次期マイナンバーカードではアイドル認証/署名で最低限の防御ができる必要があると思われます。

Windowsではスリープする瞬間に画面が真っ暗になって、中央に0.5秒程度「スリープ」なのか「シャットダウン」なのかを表示しているので、 ここで確認はできますが、凶悪犯罪組織ではゼロディなどの脆弱性を使ったOS改ざんによる攻撃を使う場合がありそうです。 PCケースの電源ボタンの点滅でスリープ状態になっていることはわかりますが、消費電力のためにOSから機能を(消灯などに)変更できる方法はあるので、 PCメーカーはスリープ状態を保証できる機能を製品に盛り込めるかもしれない。ここに期待があるかもしれないけど、くれぐれも自己責任でお願いします。

蛇足
シングルユーザーモードからのshutdownでレスキューモードで起動するとGUIで起動した。レスキューモードなのでThunderbirdなどの設定のバックアップデータを USBメモリに書き込むことができなかった。/bootの狭い空き領域に入る容量だったので/bootにバックアップデータを書き込んで、データを退避することには成功した。


11月20日 投票所の電子投票システムを次期マイナンバーカードで高信頼化

11月21日更新
自治体システム標準化の人向けですが、情報系の一般の人も。 他に方法が無いというのは理解できるのですが、投票所の電子投票システムでandroidタブレットというのは信じられないのです。 この日記の目的は、不正な選挙の温床に税金を投入するのはもったいないから、新機能を追加した次期マイナンバーカードが普及するまで、 電子投票システムの導入を抑止して、高信頼な電子投票を実現するための新機能を、コミュニティで考えていけたらと思っています。 電子投票システム不要論を語る人もあるようですが、選挙管理人が無効票になるように紛らわしい発音をしている人に僕は遭遇しています。 実際に僕は誤って無効票を投票しました。選挙管理人になるようなトップが、信頼を無くした結果、電子投票システムは必要ですと言い切れた。

以下は、3日前にSNSへ投稿した内容と同じです。
--------
次期マイナンバーカードでは電子投票システム向けの暗号化APIを装備して、TTLを使った自作CPUやLED、ボタンなどを組み上げて投票用の装置を開発すれば、良さそうな気がします。

自作CPUというよりは次期マイナンバーカードに投票データを入力して、署名されたデータを、取り出して、再度、暗号化APIを使ってマイナンバーカードで暗号化するという単機能の専用ハードが良さそうです。

自作CPUだと暗号通信に悪用される問題を考えないといけなくなるので。

自治体の電子投票システムコミュニティとか、あれば参加するかも。僕は次期マイナンバーカードに暗号プロセッサSnakeCubeが採用されることが目的です。どなたか、僕を呼んでください。よろしくお願いいたします。
--------
署名しているので記名投票ではないか?という質問ですが、無記名と同じにすることはできるかも。 まだ実際に実装できることを確認していないので、本当に実装できる保証は無いのですが、暗号化APIでPaillier暗号(加法準同型暗号)を使えば、暗号化されたデータのまま得票数を加算できます。 上位半分にマイナカードの署名。下位半分に誰に投票したかのデータ。だいたい候補者1人に4バイトを割当てると、42億人が投票しても足りる。 全てを加算したところで復号化をすれば誰が投票したのかは、加算で壊れている。

投票データをPaillier暗号化。暗号化されたデータをSHA-2(or SHA-3)でハッシュ値に。ハッシュ値をマイナンバーカードの利用者証明書で署名。さらにハッシュ値を投票所のICカードの証明書で署名。ハッシュ値と署名値2個を、RSA 4152bitで暗号化。

トラブルがあれば全ての投票を復号化して、厳密に検証することはできます。RSA暗号の秘密鍵を厳重に取り扱うことで、RSA暗号が解読されない限り、無記名は、ほぼ保証される。 RSA暗号は解読される可能性がありますが、選挙管理をしている人は、復号化をして確認することがあるので、安価な暗号のほうが良い。 もし復号化されても、利用者証明書のIDと個人を特定できるのは、限られた団体であるはず。

自治体の電子投票システムコミュニティで、本当に実装できるのかなど、議論できれば、いいのかもしれない。

次期マイナンバーカードの暗号プロセッサSnakeCubeでPaillier暗号が実装できるようにハードを開発する必要はあるので早期に検討が必要です。

次期マイナンバーカード上でPaillier暗号をするので、投票所の投票専用ハードが簡潔になって、低コストな電子投票システムになるのです。


11月17日 メインPCがサイバー攻撃の可能性のため交換作業中

メインPCがサイバー攻撃された可能性があるため、別PCをメインPCとして作り直します。 別PCの作り直しに1日以上はかかると思いますが、その後、現在のPCと別PCの2台でインターネットにアクセスすると思います。 先日、作ったLinuxサブのPCもあるので、X(旧ツイッター)のサブ垢で連絡がとれる予定です。一応、サブ垢が僕の偽物である可能性は、疑ってください。
X: https://x.com/Icf_jpn_org
Misskey.dev: https://misskey.dev/@spinlock


11月14日 音で補助入力、さらに便利にアイドル専用端末

電卓型のアイドル専用端末でフルサイズの認証をするにはRSA 4152bitでは4152bitのデータを 電卓の画面を見ながらパソコンに入力する必要があります。 7セグメント液晶では16進数表示をすることで1038桁(4152÷4)を手入力すればいいのですが、 これはかなり厳しい。7セグメント液晶では最大32種類の英数字を表示できるので人によっては、手入力を 831桁に減らせます。それでも現実的には無理でしょう。

そこで電卓型専用端末に音声入出力をつけて補助的に使う方法を考えました。 ただしパソコン側に音声入力をデータに変換するアプリをインストールする必要があるので補助的な手段として用います。

ほとんどのパソコンには音声入出力のI/Fは標準装備で、電卓側のハードが安価で、高い信頼性を確保しやすい。 メリットは大きいように思われます。

スマホでは電卓液晶画面をカメラで撮影する手段でも良さそうなので普段、スマホでしか使わない人は、 音声補助のついた電卓型専用端末である必要は無いです。ただ液晶をスキャンするアプリのインストールが必要なので、これも補助的な手段となります。

補助機能を使えば、非常に簡易な署名も可能かもしれない。

画像は普通の電卓にオーディオ ケーブルを付けただけのモックアップ画像です。

僕が数年前にFPGAボードの汎用I/Oピンを使って音声出力した動画。(あまり意味はないけど動画があったから)
https://youtu.be/7jZ0lW84bj4?si=AbSKv970tbNMwj-w


11月14日 ラピダスの2nmで交通系ICカードを作れるか?

交通系ICカードのFelicaが何故、高いのか、今まで知らなかった。 その理由はサーバーにアクセスせずに改札機でローカルに処理をしているから。 すでにSuicaはモバイルSuicaによってサーバーが構築されている。 SuicaのID化の準備が完了している、ということなのかもしれない。 つまりラピダスの2nmのロジック半導体で、思ったより低コストに次期交通系ICカードを製造できるのかもしれない。 交通系ICカードの発行枚数は、既に2億枚を超えている。

次期交通系ICカードを受注できればラピダスの大きなビジネスになるかも。

Impress WATCH記事(2023年4月7日) 鈴木淳也のPay Attention
SuicaがID化する未来。センターサーバの「新しいSuica」の意味

Impress WATCH記事(2021年4月6日) 鈴木淳也のPay Attention
「Suica」と「Visaのタッチ決済」、改札での速度差の秘密

もしかすると通信方式をMIFAREにすれば改札機は簡素化され、交通系ICカードから離脱した熊本でも、使えるようになるのかな? システムの更新費用に苦しむ交通会社も、楽になったりするのだろうか?

次期交通系ICカードは公開鍵暗号を採用し、サーバー側で秘密鍵を扱うことを避けることができれば、 安全性が高まると思います。暗号プロセッサSnakeCubeであれば自動改札機の高い要求性能を満たせるように思います。 ID化で不揮発メモリが不要になればICカードの低コストになるはず。 フューズROMをロジックと同じ、ひとつのダイに載せればいいのかも。

次期マイナンバーカードと交通系ICカードの双方を受注できれば暗号プロセッサSnakeCube(開発検討中)のライセンスの単価は下がると思うので、 是非、交通系の人も、僕のほうに直接、ご連絡ください。

ご参考
暗号プロセッサのRSA2048bitの性能実機確認


11月2日 署名法向け暗号装置、クラウドHSMの基準

デジタル庁で11月1日、 電子署名法認定基準のモダナイズ検討会(第2回)
があったようです。 今回はオンライン参加していないので公開されている資料1だけを見てコメントさせていただきます。

(B)の関する基準。重要度に応じた特攻隊による爆破突入への対応とミサイル防衛システム。 例えば次期マイナンバーカードの公開鍵暗号をAES暗号で代用する場合は、ミサイル防衛システムが必要になる場合がある。 AES暗号では狭い256bitを補うためにサーバーに状態を保持することが必要で バックアップシステムへスイッチが難しく時間がかかる。このため戦争開戦時のターゲットとして狙われる。 したがってミサイル防御システムが必要になる。

アイドル認証/署名は、状態を持たないのでバックアップシステムへのスイッチが 容易なので、ミサイル防衛システムの必要性は低い。 この建物の住人は戦争開戦時のターゲットにならないことを望むため、アイドル認証/署名という選択になる。

(C)に関する基準。アイドル認証/署名で開発する暗号装置では、暗号装置で秘密鍵を守る仕組みがしっかりしているため、 運用者は特に気にすることが無い。これは重要で犯罪が発生したときに疑われる問題が軽減される。署名は問題ないが、 認証は運用者に悪意があると利用される。

クラウドHSMに特別に求められる基準は、クラウドHSMで署名を実行する条件が、安全であること。 パスワードを条件にすれば、盗まれると、悪人にクラウドHSMの署名を奪われるので問題が大きい。 絶対に安全な条件である必要があると思われます。つまり、ほぼ絶対安全なアイドル認証以外、 これを満たすことは、難しい。

突っ込んでいえば次期マイナンバーカードの公開鍵の選択をクラウドHSMにして 暗号プロセッサSnakeCubeの開発を回避するためには、アイドル認証が必要になって暗号プロセッサSnakeCubeの開発が必要になる。 余計なことを言うと、SnakeCubeを回避するために、より大きな問題を発生していることに注意してみることも重要かも。


暗号プロセッサ OpenICF3