時間ベースのOTPが必要な状況があります。
しかし、私が見たほとんどの例とケースでは、同じキーを使用してOTPを作成およびチェックしています。
しかし、私は何か違うものが必要です。公開鍵を使用してOTPを作成し、秘密鍵のみを使用してチェック/復号化できるようにしたい。
このような方法はありますか?
時間ベースのOTPが必要な状況があります。
まず、時間ベースのOTP(または)時間同期OTPの基礎を思い出してみましょう。 TOTPは、OTP生成のプロセスでクライアントのTIME(リアルタイムクロック)を使用します。したがって、「時間」要素は公開鍵と秘密鍵であると言っても安全です。
しかし、私が見たほとんどの例とケースは、同じキーを使用してOTPを作成およびチェックしています
このクエリはTOTPの概念と完全に矛盾しています。間違っている場合は修正してください。後で、別のものが必要だと主張し、私がこれを正しく理解した場合、クライアントのTimeを使用してOTPを生成し、サーバーはクライアントのローカル時間を認識します...このようにして、ユーザーが生成したOTP(クライアント)はサーバーによって認証されます。しかし、サーバーのクライアントのローカル時間の同期にほかならない秘密鍵でチェックする必要があります。したがって、TOTPでの公開鍵/秘密鍵の参照を停止してください。
編集:(コメントを読んだ後)サーバーはクライアントのローカル時間と同期する必要があるか、TOTPの概念が失敗します...これ以上の事実を強調することはできません。
One Time Password
について話している場合、単純な理由があります。TOTPアルゴリズムがクライアント/デバイスとサーバー側で対称鍵を使用している理由です。
HOTP-TOTP(RFC6238)を見ると、イベントベースのOTPアルゴリズムであるHOTP-OTP(RFC4226)から派生しています。これは2005年に明記されました。最初のスマートフォンは2007年に登場しました。
だから何? OTPアルゴリズムは、ハードウェアデバイスで動作するように設計されています。これらのハードウェアデバイスにはディスプレイがあり、ユーザーはワンタイムパスワードを入力できます。ワンタイムパスワードの生成中、RFCは切り捨て方法を定義するため、ユーザーは実際には限られた文字セットをパンチインできます。 HMAC-SHA1の出力は20バイトの16進コードです。これをワンタイムパスワードとして入力する必要はありません。
非対称暗号化を実行できるようにするには、cannot切り捨て関数を使用します。そうでない場合、公開鍵は署名を検証できません。秘密鍵はメッセージを復号化できません。非対称キーで転送するデータははるかに大きくなります-1024ビット、2048ビット...ここでも、ユーザーは非常に長いワンタイムパスワードを手動で入力する必要があります。
まあ、クライアントがこのデータを電子的に送信する場合は、データを切り捨てる必要はありません。ただし、ここでも、ワンタイムパスワードについてではなく、公開キー暗号またはクライアント証明書ベースの認証について説明しています。
つまり、最終的には人間の可読性と切り捨てがすべてです。