アイデアは思いついたのですが、Google で魔法の言葉を使用する方法がわかりません。ここでアイデアを説明したいと思います。誰かが私が探しているものを知ってくれるかもしれません。
データベースがあるとします。たくさんのデータ。暗号化されています。私が探しているのは、復号化するための暗号化です。変数 N は、特定の時点で値 M (ハードウェアトークンなどのサードパーティから取得) を保持する必要があります。そうでない場合、復号化に失敗しました。
AES を想像してみてください。AES は 1 つのキーにすぎません。鍵を持っている場合は、その中にいます。ここで、アルゴリズム自体が鍵以外の追加の事実を必要とするような方法で変更された AES を想像してください。外部ソースからのこの追加のデータと、そのデータが時間とともに変化する場所です。
これは存在しますか？名前はありますか？
これは、信頼できるサードパーティの助けを借りて簡単に行うことができます。ええ、私は知っています、おそらくあなたはそれを必要としない解決策を望んでいますが、私に我慢してください—私たちはそれに到達するか、少なくともそれに近づくでしょう.
とにかく、適切な信頼できるサードパーティがあれば、これは簡単です。ファイルを AES で暗号化した後、AES キーをサードパーティに送信し、サードパーティに独自のキーで暗号化するよう依頼し、結果を返信します。 、および将来の特定の時点でキーを公開します。その時点で (しかしすぐに)、暗号化された AES キーを持っている人は誰でもそれを解読し、それを使用してファイルを解読できるようになります。
もちろん、サード パーティは多数のキー暗号化キーを必要とする場合があり、それぞれが異なるタイミングで公開されます。それらすべてをディスクなどに保存するよりも簡単な方法は、秘密のマスター キーと指定されたリリース時刻から各キー暗号化キーを生成することです。たとえば、適切なキー派生関数をそれらに適用します。このようにして、任意のリリース日またはリリース時刻に対して、別個の (明らかに) 独立したキーを生成できます。
場合によっては、このソリューションが実際に実用的な場合もあります。たとえば、「信頼できるサード パーティ」は、組み込みのリアルタイム クロックと安全な外部インターフェイスを備えた改ざん防止のハードウェア セキュリティ モジュールであり、リリース日を問わずキーを暗号化できますが、リリース日のみを復号化できます。合格しました。
ただし、信頼できるサード パーティがグローバル サービスを提供するリモート エンティティである場合、暗号化のために各 AES キーをサード パーティに送信することは非現実的であり、潜在的なセキュリティ リスクは言うまでもありません。その場合、対称暗号化を使用する代わりに、公開鍵暗号化が解決策を提供できます。ファイル暗号化キーを暗号化するには (ファイル暗号化キーを知るか、キー暗号化キーを解放する必要があります)、信頼できるサード パーティは、代わりにリリース日ごとに公開/秘密キーのペアを生成し、公開半分を公開できます。ただし、指定されたリリース日まで秘密鍵の公開を拒否します。公開鍵を保持している他のユーザーは、それを使用して自分の鍵を暗号化できますが、対応する秘密鍵が開示されるまで、誰も復号化できません。
(別の部分的な解決策は、秘密共有を使用して AES キーを共有に分割し、1 つの共有のみを暗号化のためにサード パーティに送信することです。上記の公開キー ソリューションと同様に、これにより、AES キーをサード パーティに開示することを回避できます。ただし、公開鍵ソリューションとは異なり、暗号化者と信頼できるサード パーティとの間で双方向の通信が必要になります。)
上記の両方のソリューションの明らかな問題は、あなた (および関係者全員)がキーを生成するサード パーティを信頼する必要があることです。時間。
ただし、 Michael Rabin と Christopher Thorpe によって 2006 年に公開された(著者の 1 人によるcrypto.SE に関するこの回答で言及されている)巧妙な方法があり、少なくとも部分的に問題を回避します。その秘訣は、多かれ少なかれ信頼できるいくつかのサードパーティのネットワーク間でキー生成を分散させ、限られた数のパーティが不正または危険にさらされたとしても、十分な過半数になるまで誰も秘密キーを知ることができないようにすることです。の当事者は、実際に解放する時が来たことに同意しています。
Rabin & Thorpe プロトコルは、指定された時間に秘密鍵が開示されないようにする試みや、生成された秘密鍵または公開鍵を一致させない試みなど、侵害された当事者によるその他のさまざまな可能性のある攻撃からも保護します。彼らのプロトコルを完全に理解しているとは言いませんが、既存の暗号技術とよく研究された暗号技術の組み合わせに基づいていることを考えると、規定されたセキュリティ仕様を満たさない理由はわかりません.
もちろん、ここでの主な困難は、これらのセキュリティ仕様が実際に有用なものになるためには、1 人の攻撃者がそれらの十分な大部分をもっともらしい方法で侵害できないように、十分な大きさのキー ジェネレータの分散ネットワークが必要であるということです。このようなネットワークを確立して維持することは簡単なことではありません。
簡単な答えは「いいえ」です。すべてのデータベースを定期的に復号化して再暗号化しない限り、データの復号化に使用されるキーは時間内に変更できません (実現可能ではないと思います)。
@Ilmari Karonen によって提案されたソリューションは実行可能な唯一のソリューションですが、信頼できるサードパーティが必要です。さらに、マスター AES キーを取得すると、将来再利用できます。そのソリューションで「ワンタイムパッド」を使用することはできません。
トークンを時間ベースにしたい場合は、TOTP アルゴリズムを使用できます
TOTP は、特定の時間 M で変数 N (トークン) の値を生成するのに役立ちます。したがって、データベースへのアクセスを要求するサービスは、TOTP を使用して生成されたトークンを添付します。アクセス プロバイダー側でのトークンの検証中に、トークンが現在の時刻に基づいて正しい値を保持しているかどうかを検証します。同じ TOTP を生成するには、両端に共有キーが必要です。
TOTP の利点は、値が時間とともに変化し、1 つのトークンを再利用できないことです。
二要素認証についても同様のことを実装しました。
「ワンタイムパスワード」はあなたのグーグルワードかもしれません。
他の人が指摘したように、ワンタイム パスワードはあなたが提案したシナリオの良い解決策かもしれません。
https://code.google.com/p/otpnet/を見ることができるC# で実装された OTP があります。