none
デスクトップアプリケーション(WPF)の秘密鍵の保存方法について RRS feed

  • 質問

  • こんにちは。
    件名のとおり、デスクトップアプリケーション(WPF)における秘密鍵の保存方法について質問です。

    秘密鍵はユーザーに、鍵を取られないように設計するものだと思います。
    (http://garafu.blogspot.jp/2015/12/rsacryptgraphy.html)

    例えば、一台のコンピューターに限定するのであれば、下記のようにキーコンテナ―に保存するものがありました。
    (http://devadjust.exblog.jp/20400427/)

    しかし、(ソフトウェアの要件として)インストールしたすべてのPCにおいて、なんらかのデータの暗号化と復号化をする場合、どのように考えればよいのでしょうか。
    なお、すべてのPCはインターネットに接続しないローカルなものが多いため、DB利用も不可能です。(あって、PCごとのSQLite)

    例:
    PC(A)がデータ1を暗号化して保存して、PC(B)がデータ1を復号化して読むことがある

    こうした場合は、ファイルまたはレジストリに、自前で何か暗号化して保存する形になるのでしょうか。デスクトップアプリケーションでは、どのように設計されるのでしょうか。


    以上です。よろしくお願いします。

    2016年6月21日 6:16

回答

  • 一塊のデータの、部分の改ざんを防止する方法として、
    一般的なものとして「チェックサム」値を埋め込むという方法があります。
    暗号化より簡便なため使用されることが多いです。
    詳しくお話しできませんが、たとえば、医療目的等で撮影した写真画像などに利用されている例を知っています。
    もちろん、この場合データのフォーマット全体を非公開としています。

    2016年6月22日 2:24

すべての返信

  • 「アプリケーション内で秘匿し、ユーザーには絶対に知られたくない」ということを求めていますか?
    正直なところ、アプリケーションをユーザーが入手できる時点で、その気になれば解析・解読可能です。

    ASP.NET の事例を示されていますが、それはあくまでプログラムがユーザーの手元になく、処理した結果をユーザーが受けとるからこそ秘匿できるのです。
    アプリケーションそのものを渡してしまうデスクトップアプリでは意味がありません…。

    鍵を秘匿したいなら、Web サービスとして設計するなど、鍵やソースコードを相手に渡さずに済む方法が真っ先に考えられます。
    あとは、ハードウェアキーなど、特殊なデバイスを使うぐらいでしょう。
    そこまでの堅さを求めないなら、ソースコードに直接書くのとあまり差はないと思っています。

    2016年6月21日 14:16
  • 秘密、というのは、誰に対して秘密なんですか?

    秘密のトークンの話ですか?
    ソフトをインストールしたAlice、Bob、Charieがいるとして、
    ・Aliceはソフト内蔵鍵でファイルを暗号化して、ファイルをBobに渡すと、Bobはソフト内蔵鍵で復号する。
    ・ファイルを拾ったCharieも、ソフトがインストールずみなので、ファイルは復号できる(アプリがあれば誰でも復号できる)
    ・ただし、鍵が裸で公開されるのはまずい

    それとも、デジタルテレビとかDVDプレイヤーみたいな機構の話なんですか?
    ・発信元が共通鍵で暗号化して、広く配布する
    ・発信元から信頼されているプレイヤーが、内蔵している共通鍵でデータを復号し、表示する
    ・共通鍵が裸で公開されるのはまずい(信頼されていないプレイヤーが出てくるから)

    あるいは最初のURLで挙げられたような、公開鍵暗号の話ですか?
    ・Alice,Bob,Charieは、全員の公開鍵は全員が知っている。秘密鍵は自分の分しか知らない
    ・AliceはBobにたいするメッセージを、Bobの公開鍵を使って暗号化して、Bobに渡した。
    ・Bobは秘密鍵をつかってファイルを復号できる。
    ・Charieはファイルを拾ったがBobの秘密鍵がないので中身は解らない。


    jzkey

    2016年6月21日 15:27
  • Azuleanさん、jzkeyさん回答ありがとうございます。

    デスクトップアプリケーションなので、どうしても鍵をPC内のどこかで保管することになるため解析可能だ、というのは理解するところです。
    なので「絶対に」解析解読できない、というのは現実的な問題として無理があると理解しています。

    要件をすこし整理します。
    まず、ソフトウェアは、Webサービスなどは不可能で、絶対にデスクトップアプリケーションとなっています。
    これは、機器とシリアル接続(COMポート等)することもありますが、開発の都合というよりも、多数ユーザーの慣例としてそれ以外の選択肢が与えられないためです。

    暗号化するものは、制御機器、分析機器(例えば、天秤の秤量値など)によって、計測したなんらかの「計測データ」です。
    このデータを直接改竄されたくないため、データを暗号化して隠蔽したいと考えています。

    単独で動く昔ながらのPCのアプリケーションで、データのセキュリティとして上書きや改竄から保護できる、となっているものもあるようで、そうしたものが近い環境です。

    しかし、データの暗号化は、具体的な実装を指示するものではなく、(抽象的に)データが安全で改竄できない、ことが要件になります。これ以上、具体的な回答は望めない状態です。
    改竄できない(安全であること)、というところが、Azuleanさんのおっしゃるとおり、「堅さ」の問題になるのかと思います。

    例えば、以下のようなことを考えています。
    ・ソースコード内で鍵を管理していても、最低限要件を満たすことになるのか。
    ・SQLiteにユーザーマスターのようなものを用意して、ユーザー単位に紐づく鍵をDB内で保管する。
    ・ユーザーになにかパスワードを入力させて、それを保管する。
    Azuleanさんのいうとおり、どれもあまり(堅さにおける)差はないのだと思っています。

    知見をもつ者がおらず、どうしたところが現実的なデスクトップアプリケーションにおけるデータ保護になるのか、というところです。
    要件によって異なります、という話だとは思いますが、指針を含めて、なにか考えるヒントが欲しい状態です。

    2016年6月22日 1:35
  • 一塊のデータの、部分の改ざんを防止する方法として、
    一般的なものとして「チェックサム」値を埋め込むという方法があります。
    暗号化より簡便なため使用されることが多いです。
    詳しくお話しできませんが、たとえば、医療目的等で撮影した写真画像などに利用されている例を知っています。
    もちろん、この場合データのフォーマット全体を非公開としています。

    2016年6月22日 2:24
  • 仲澤さん 回答ありがとうございます。

    チェックサムも確かによいですね。暗号化してとりあえず見えないようにすることに注視していました。
    検討してみたいと思います。

    2016年6月22日 2:40
  • 要件はだいたいわかりました。あとは、どのくらいの費用を掛けるに値するか、という話になります。

    ようするに、「ユーザー」のスキルとして、「ソフトを逆コンパイルしたり、逆アセンブルしたり、ソフトをバイナリ改造したりする」レベルなのか、
    「とりあえず、チェックサムをつけておけば手も足も出ない」、というレベルなのかです。

    そして、秘匿性にたいしてどの程度支払ってもよいか、です。たとえば、ぐぐっただけで、http://www.macnica.net/arxan/transform.html/
    あたりがひっかかりますが、たぶん、数十万円とかのオーダーになる気がしますし、ソフト自体の暗号化とか鍵の秘匿処理をかける手間も必要でしょう。


    jzkey

    2016年6月22日 2:45
  • jzkeyさん 回答ありがとうございます。

    上記のとおり、具体的な線引きが難しいため定量的にどのレベルでよいのかを定めづらいです。
    費用をかける価値からは、詳しい説明が難しいです。すいません。

    ソフトウェア自体の暗号化は言われてみれば、埋め込んだりチェックサムをするなら特にそうか、と思うところです。
    いくつかアイデアが増えたので、もう少し整理してみるようにします。

    2016年6月22日 7:11