26
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

nemAdvent Calendar 2021

Day 2

Symbolブロックチェーンでクラウドサービス不要のログインを概念検証する

Last updated at Posted at 2022-01-04

今回はSymbolブロックチェーンを活用した認証基盤の構築について概念検証してみたいと思います。

Symbolはブロックチェーンに詳しくない他分野のスペシャリストでもローコード/ノーコードでセキュアかつデプロイレスなスマートコントラクトを記述できるブロックチェーンとして日本のエンジニアや研究者を中心に注目されていて、いまでは元ビットコインのPoWやイーサリアムのプロトコルの改善提案者がコアチームに参入するなど新しい経済圏を実現するプラットフォームとしてその可能性が期待されています。

ログイン

KYCなどが済んだユーザに対して、譲渡不可・リボーク(収受)可能なトークンをログインチケットとして付与します。(ユーザが秘密鍵を所有しない場合は新規にアカウントを生成してそこに付与します。)

image.png

以後、ログインを希望するユーザに対してログインチケットをリボーク可能かどうかでログイン可能かどうかを判断します。2重ログインを禁止したい場合は、ユーザのログアウト・タイムアウトを判断した後、ログインチケットを返却します。2重ログインも許容できる場合はリボークトランザクションと付与トランザクションのアグリゲートトランザクションで早々に再交付しておきましょう。

image.png

セッション管理

今回はセッションハイジャックが困難な、1度しか使えない有効期限つき(30分)ワンタイムセッションを実現します。

セッションキー発行

ログイン可能と判断できたユーザに対して、セッションキーを付与します。
最初のセッションキーはユーザからログインチケットを収受したリボーカブルトランザクションのHash値です。

同時にそのHash値をバリューとしたメタデータを、ユーザの公開鍵をキー値としてサービスプロバイダ自身に登録しておきます。これが未使用Hashの証明になります。(1アカウントに登録できるメタデータの最大数にご注意ください。ユーザのアカウントにメタデータとして登録する方法もありますが、その場合はユーザ側の秘密鍵が必要になります)

サービスプロバイダ.metadata{Key:Value} = {ユーザーの公開鍵:セッションキー(リボーカブルTX.hash or セッション更新TX.hash)}

image.png

セッションキー更新

ユーザはページ遷移ごとに、セッションキーを秘密鍵で署名した値をサービスプロバイダへ提出します。この作業にブロックチェーンは必要ありません。
サービスプロバイダはセッションキーからブロックチェーンへ照会し、そのTXのタイムスタンプと提出者のアカウントを確認します。(ユーザが署名できない場合はサービスプロバイダ自身が発行したトランザクションの情報を信用してユーザを特定します)

タイムスタンプが現在時刻から30分以上経過している場合は、後述のタイムアウト処理を実行します。また、受け取ったセッションキーがメタデータに登録されていない場合も無効なワンタイムセッションとしてタイムアウト処理を実行します。

セッションキーの更新はユーザのパブリックキーをメッセージに含めてサービスプロバイダ自身にTX送信し、その時のトランザクションハッシュ値をユーザに伝えます。同時にハッシュ値を未使用のセッションキーとしてメタデータに更新しておきます。

image.png

タイムアウト

セッションキーに紐づけられたトランザクションが古い場合、ユーザにログインチケットを返却しタイムアウト処理を行います。ユーザは再び秘密鍵を使用してログイン申請に署名する必要があります。ユーザがセッションキーを紛失した場合は、別途KYC手段によりログインチケットを再発行します。

情報提供

セッションの検証により所有者が特定できたら、紐づくデータをユーザに開示します。
今回はユーザによるセッションキーへの署名で所有者を特定しましたが、ユーザによる署名が困難な場合は、サービスプロバイダ側のDBでセッションと対応するアカウントリストを保有しておいてもいいかもしれません。もちろんセッションキーはHTTPSなど別のセキュリティで保護する必要が出てきます。

まとめ

今回はKYCがあるシーンでの有効期限つきワンタイムセッションという認証基盤について考えました。少しセキュリティを厳密に定義しましたのでブロックチェーンに依存する部分が多いですが、タイムアウトやセッションの再利用など要件に応じてブロックチェーンへの依存度を低めることも可能です。要点はトランザクションハッシュがそのままセッションキーとして利用できるという点で、ログインや画面遷移するたびにトークンが貯まるといった仕組みへ展開していくことが簡単なことを感じていただければと思います。逆にページ遷移するたびにトークンを消耗していくようなサイト構築も可能でしょう。

また、クラウドサービスなどに依存しない認証基盤の構築は非常に興味深いテーマだと思います。
今回は単純なテーマで検討しましたが、今後ブロックチェーンが普及するとサービスプロバイダが複数にわたるといったユースケースが増えてきます。そういったときに認証基盤を切り離すことが出来れば、よりフラットな経済圏を構築することが出来るかもしれません。

追記

現在この記事が注目されているようですので、お勧めの記事を紹介しておきます(順次追加しております)。

Symbolブロックチェーンの可能性を感じてみたい方

他の技術とSymbolを組み合わせてみたい方

とりあえず送金を試してみたい方

26
11
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
26
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?