Home

2019年
2020年

6月28日 HCVのリバースエンジニアリング対策

ツイッターに英語の論文の紹介があったので、何の気なしに、見てみた。 日本の論文だから詳しいことは日本語のスライドを探せばいいのかと思いながら、ナナメ読みして、ふっと思いついた。 そういえばHCVのUSBデバイスのファームに書かれている公開鍵のデータを 暗号化しておけばリバースエンジニアリング対策になるかと思った。 そしてUSBデバイス毎に異なる暗号化データになるような仕組みにしておけば、別のデバイスにコピーされることはない。 方法は、48bit程度のシード(メーカー24bit、ユーザー24bit)を8bit CPUのライト・オンリーメモリにUSBデバイス事に書いておく。 そのシードと基板情報をもとにチップ内で128bitのデータにする。 8bit CPUはAES暗号のサブルーチンを読んで新しい128bitの鍵を作る。 それを使って公開鍵のデータをAESで暗号化してファームに書き込む。 専用のカギ導出回路を使う手もあるが、AES暗号で代替すれば、専用回路なしで済む。


6月27日 RSA署名と検証の演算量の違い(改訂版)

昨日の日記でRSA検証のみの8bit CPU搭載のUSBデバイスが、かなり安価という説明をしました。 これまで普通に使われているUSB認証デバイスはRSA検証ではなくて、RSA署名の演算です。 RSA署名と検証で、どのくらい演算量が違うのかをopensslのspeedコマンド (第4世代Core i3)で調べると、約30倍違います。 つまり検証のみならCPUのスペックは、かなり低く抑えられるのです。
厳密に言うとHCVで必要な処理は、SHAなどのハッシュ演算とRSA検証の演算になります。 大きなファイルではハッシュ演算が8bit CPUでは性能的に問題になる可能性がありますが、 そういう場合はファイルのハッシュ値の記載されたテキストの検証ということにすればハッシュの性能は問題なくなります。


6月27日 Linuxのソフトウェア配信にはいいかも

LinuxにはWindowsのような証明書のROOTストアがないのでコードサイニング証明書が使われていない場合も多い。 そういったソフトウェアには寄付を兼ねてHCVはいいかもしれない。


6月26日 HCVはコードサイニング証明書を代替できるか?

HCV(Hard Code Verifier)は、RSA検証のみの8bit CPU搭載のUSBデバイスが、 かなり安価であることに目をつけたものです。 ただしHCVはソフトウェアを配信する人が、8bit CPU搭載のUSBデバイスを利用者に確実に届ける手段がない限り、 コードサイニング証明書の信頼性に及びません。
フリーソフトに寄付しても、何のリターンもない問題を解決するのにいいのかもと考えています。 コードサイニング証明書か、HCVか、どちらでもいい場合、HCVになることもあるので、 コードサイニング証明書の市場が小さくなることはあると思います。 やはり、僕にとって、このあたりは問題なのかも。 HCVを含めた全体としては市場は大きくなっているはずなのですが。


6月23日 サブの日記をはじめました

いろいろな話題、とりあえずHCV(Hard Code Verifier)の話題について、思ったことを書いたり、 メインの日記noteと同じことを書くこともあります。


暗号プロセッサ OpenICF3