当初の予想よりも時間がかかったが、Lavabit の創設者 Ladar Levison 氏の Dark Mail Technical Alliance の最初の成果は、同氏が 2013 年に閉鎖した暗号化メール サービスの再開という形で現れた。
ラバビットを閉鎖した後、レヴィソンはサイレント・サークルと手を組んでDMTAを設立し、2014年にラバビットが再び運行することを約束した。
2015年、レヴィソン氏はGitHubリポジトリに投稿し、完全に「ダーク」な電子メールをサポートするプロトコルを提案した。そのプロトコルとは、複数層のキー管理と複数層のメッセージ暗号化を備えたダークインターネットメール環境（DIME）である。
Libdime 実装では、ライブラリとコマンド ライン ユーティリティの両方が提供されていましたが、これは結局のところ、困難な方法でした。Lavabit Mark II では、これもオープン ソースの Magma Webmail サーバー実装によって、ユーザーがそれを実行できるようになりました。
Lavabit メール サーバー Magma は、2016 年に GitHub に初めて登場しました。
Levison氏は次のように述べています。「DIMEは複数のセキュリティモード（Trustful、Cautious、Paranoid）を提供し、他の暗号化プラットフォームとは根本的に異なるため、他社が見落としているセキュリティ問題を解決します。DIMEは、中央集権的な機関を介さずにメタデータの漏洩を最小限に抑えながら、複数のサービスプロバイダーと連携するように設計された、唯一の自動化されたフェデレーション型暗号化標準です。DIMEはエンドツーエンドで安全でありながら、暗号学の博士号を持っていなくてもメールを使い続けられるほどの柔軟性を備えています。」
では、このプロトコルには何が含まれているのでしょうか？ここで公開されている仕様（PDF）を見てみましょう。
DIMEのメッセージフロー。画像: The Dark Mail Technical Alliance
ウェットウェアが絡んでいる限り、完璧なセキュリティは実現できません。DIMEの文書では、ユーザーのパスワードが弱かったり、エンドポイントのセキュリティが不十分だったりすると、すべてが台無しになると指摘されています。
DMTA によれば、その制約の中で、DIME は「メッセージの機密性、改ざん防止、および配信パスで遭遇する処理エージェントへのメタデータ漏洩の大幅な削減を実現しながら、安全で信頼性の高い電子メール配信」を提供するように設計されているとのことです。
最上位レベルでは、システム アーキテクチャの 4 つのコンポーネントは、電子メール クライアント、プライバシー処理エージェント、キー ストア (キーを取得するためのリゾルバ アーキテクチャを備え、DIME では「シグネット」と呼ばれます)、および暗号化されたメッセージ オブジェクトです。
ほとんどのユーザーにとって、The Registerはここでの新しい概念はプライバシー処理エージェント（PPA）だけであると考えているでしょう。PPAには、組織PPAとユーザーPPAの2種類があります。
組織プライバシーエージェント（OPA）は、ユーザーのメールクライアントとインターネット全体の両方と通信し、ユーザーの鍵管理を行うことで、「トランスポート層セキュリティを用いてメッセージに関するすべての情報を秘匿する安全なトランジットチャネル」を構築します。また、「即時の処理に必要なエンベロープ情報へのアクセスも提供します。」
ユーザー プライバシー エージェント (UPA) は、ユーザー側の暗号化機能を処理し、ユーザーの電子メール クライアント内、または Web メール実装の場合はサーバー上に配置できます。
DIME には 3 つの動作モードがあります。
- 信頼性 – ユーザーはサーバーがプライバシーを処理することを信頼します。
- 慎重 – サーバーは、秘密鍵とメッセージの暗号化されたコピーを含む、暗号化されたデータを保存および同期します。暗号化はユーザーのブラウザ内で実行できます。
- パラノイド – サーバーはユーザーの鍵を一切認識しません。Webメールはなく、複数のデバイスを使用する場合は、異なるキーリング間で同期させるのはユーザー自身に任されています。
技術的に言えば、システムはキー管理のあらゆる側面を自動化し、ユーザーが実行方法を学習することなくメッセージを暗号化して署名し、操作に耐える必要がある (理想的には、クライアントが侵害された場合でも) ことを意味します。
この標準規格によれば、暗号化の階層化は、（たとえば）途中のサーバーが侵害された場合でも、メッセージを保護するように設計されている。
DIME は、キーの「署名」の概念に依存しています。組織の署名はドメインに関連付けられたキーであり、ユーザーの署名は個々の電子メール アドレスに関連付けられたキーです。
基本的な検証モデルは、信頼できる一次情報源から署名を取得し、それを別の事前認証済みの情報源で確認することです。現在利用可能な2つの事前認証済みの情報源は、DNSSECを使用して署名された管理レコードと、認定された認証局（CA）によって署名されたTLS証明書です。どちらも、署名リゾルバによって暗号的に追跡され、リゾルバに同梱されている信頼できる鍵まで遡ることができます。
Lavabit 社では、Web メール バージョンに加えて、Windows、Mac OS、iOS、Linux、Android 向けのクライアントも開発したいとしています。®
