MeldID：単一アカウントからデジタルアクセス管理システムへ

私が初めてMeldIDを理解したとき、それは主に単一のデジタルIDインフラストラクチャとして捉えていました。ユーザーは1つのアカウントを作成し、管理可能なプロファイルに入力し、それをさまざまなアプリケーションで使用できます。これにより、繰り返し入力することなくログインや許可されたデータの送信が可能になります。

私は今後の展開がプロファイルや接続されたサービスの側へ進むと予想していました。しかし、プロジェクトはすぐに、ほとんど目立たないサーバーインフラストラクチャから日常的なアクセス管理ツールへと変貌を遂げ始めました。

次のステップは、iPhoneとAndroid向けのアプリの登場です。特に興味深いのは、モバイルクライアント自体の出現だけでなく、その中で融合されたタスクです。

単なるTOTP — しかし異なる目的

アプリにはワンタイムパスワードTOTPを生成する機能があります。これは、多要素認証に使われる変化する数字のことです。

この標準は自己発明ではなく、ユーザーはアカウントを追加し、外部サービスやウェブサイトで使用できるコードを受け取ります。

ほとんどの認証器は、「6桁のコードをどう表示するか？」という問いに答えます。ここではより広範な課題、すなわちTOTPシークレットのライフサイクル管理 — 追加・保存・別デバイスへの復元・削除 — に対応しています。

オフラインモードは完全に機能する

一見、最大の利点はローカルでコードを生成できることだけに思えます。しかし、MeldIDではオフラインモードはそれ以上のものです。

すでに保存された記録はインターネットなしでも動作し続けます。コードは直接電話上で生成されるため、一時的な接続遮断でも二要素認証を通過できます。

新たなTOTP記録もオフラインで追加可能で、ローカルに保存され、すぐにコード生成に使用されます。インターネットが復旧すれば、その追加は自動的に安全なストレージに送信され、他のデバイスと同期されます。

既存記録の編集や削除はサーバーへの接続が必要です。これにより、異なる端末で同じストレージのバージョンが異なることを防ぎます。

その結果、ネットワークなしでも基本操作が可能であり、すべてのデバイスに均一に適用される変更のみがオンライン復帰後に行われるバランスが得られます。

新しい電話は新しいコードセットを意味しない

どんな認証器にも最も困る問題は、電話の紛失、故障、交換後に発生します。通常、リザーブコードを探したり、記録を手動で移行したり、各サービスに再設定したりする必要があります。

ここでのストレージは特定のデバイスではなく、MeldIDアカウントに結びついています。新しい電話でログインし、保護されたストレージを初期化すれば、自動的に記録も復元されます。

以前の端末がAndroidかiPhoneかは問いません。第2、第3の端末も、プラットフォームごとの移行作業なしに利用可能です。

たとえば、旅行中に突然スマホが故障した場合、各サービスへのアクセスを回復する代わりに、ユーザーは新端末でMeldIDにログインし、ストレージ設定を完了します。その後、TOTP記録がアプリに戻ります。

1台の端末上で複数のMeldIDアカウントを使用することも可能です。それらのストレージは分離されており、あるアカウントの記録は他のアカウントと混ざらず、適切な認証なしには端末上に表示されません。

サーバーに保存されるもの

自動復元はデータのどこかへの保存を意味します。ただし、TOTPシークレットは平文で保存されません。

記録の内容は暗号化されたコンテナに格納されます。現在のアーキテクチャでは、認証済みAES-256-GCM暗号化が使用されており、暗号キーはデータベースから分離されています。

そのため、1つのデータベースの漏洩が、そのままコード生成用のシークレットリストにつながることはありません。攻撃者は暗号化されたブロックのみを入手し、TOTPデータは見られません。

絶対的な保証をしないことも重要です。つまり、平文のTOTPシークレットはデータベースに保存されませんし、データベースのコピーだけではシークレットを利用できません。

ログイン承認（Login Approval）による認証

アプリのもう一つの重要な機能はLogin Approvalです。これは、認証を別途確認する仕組みです。

サイトやアプリがMeldIDをサポートしている場合、ユーザーは一つの操作でアカウントにログインできます。認証保護が有効な場合、成功だけでは不十分であり、信頼されたモバイル端末での確認が必要です。

本当にユーザー自身がログインを開始した場合に承認し、異常な操作と思われる場合は拒否できます。

通常のプッシュ通知による承認と違い、Login ApprovalはMeldIDのアーキテクチャに組み込まれており、この認証システムに接続されたすべてのサービスで利用可能です。

プッシュ通知は新規操作の通知だけで、パスワード、TOTPコード、トークンなどの認証情報は含まれません。

TOTPとLogin Approvalは相補的

TOTPは引き続き普遍的な標準であり、MeldIDについて何も知らないサービスでも動作します。記録をロードすると、コードはローカルで生成されます。

Login Approvalは、認証自体がMeldIDを通じて行われる箇所で必要です。ユーザーの意識的な操作を追加し、セッション開始前に試行を止めることを可能にします。

そのため、アプリはサードパーティのサイト用の認証器としてだけでなく、接続されたシステムへのログイン確認手段としても機能します。

MeldIDに何が起きたか

私が最初にこのプロジェクトについて知ったとき、それの基本的なアイデアは単一アカウントの管理と持ち運び可能なプロファイルでした。今では、MeldIDが徐々にデジタルアクセスの個人管理センターへと変化していることが明らかになっています。

具体的には、ここでは次のことが可能です：

• インターネット不要でTOTPコードを取得

• 新しい記録をオフラインで追加

• 新端末へ自動復元

• 複数の電話を使用

• 複数アカウントを1つの端末で分離管理

• 新しいアクセスを承認または拒否

アプリの価値は、次に示すことにあります。それは6桁のコードを表示する能力だけでなく、端末の変更時にアクセスを維持し、ネットワーク外でもデータを失わず、最後に所有者に新しいセッション開始前の意識的な選択肢を与えることです。

ここでの安全性は、単一のメカニズムではなく、複合的な解決策の総体に支えられています。TOTPシークレットは平文では保存されず、アクセスは一度だけではなく、異なる端末に永続的に紐付けられず、複数のアカウントは分離され、対応するサービスへのログインは信頼された端末の確認後のみ完了します。