UML ダイアグラムを使用して、エンタープライズ セキュリティ ソリューションの暗号化を説明できます。私はエンタープライズ ソフトウェア ビジネスで働いている間、セキュリティ ホワイト ペーパーや同様の説明文書に貢献したので知っています。

私がUMLを使う理由

数年前、セキュリティ エンジニアから、ソリューションの暗号化リソース間の関係について口頭で説明を受けていました。質問をしていると、ワイプボードにボックスとラインを描き始めました。セキュリティ エンジニアは、いくつかのボックスと線を消去して再描画することで、私の理解を修正しました。携帯電話で写真を撮り、コンピューターの描画ツールで図を転写しました。

その後、同じ仕事で、私が取り組んだ製品のセキュリティ ホワイト ペーパーに貢献していました。私は、その暗号リソース間の関係を図で表現するために、その場しのぎの規則を思いつきました。

その後、別の仕事で、図を含むセキュリティ ホワイト ペーパーを再び書いていました。それは私の前の雇用主の知的財産だったので、私は同じアドホックな慣習を利用することができませんでした. そこで、私がすでに慣れ親しんでいる統一モデリング言語 (UML) に目を向けました。

ツールキットとしての UML

UML 標準の大きな価値の 1 つは、ツールを提供し、規範的ではないことです。私の UML は厳密ではありません。標準的な要素を非標準的な方法で使用することがあります。しかし、私の図は、Martin Fowler が「最も有用な UML の一部」と述べたものに準拠しています。

UML 標準は、ソリューションの暗号化を説明するのに役立つツールです。

説明すべきこと

以下のすべてをUMLで説明します。

• ソリューションの主要な暗号化リソースは何ですか。たとえば、どのような暗号化キーとソルト値が存在するか。
• 使用されるアルゴリズム。
• キーとソルト値のビット単位の長さなど、使用されるパラメーター値。
• 各暗号リソースの生成方法。
• どの暗号化リソースが永続的に保存され、どこに保存され、どの暗号化リソースが保存されていないか。
• どのリソースがどのキーによって保護されているか、つまりキー階層。

私が提供する説明は、十分に詳細ではないため、競合他社が製品を真似することはできません。あなたは別の考え方をするかもしれません。その場合、あなたの説明を見たいと思っている外部関係者から秘密保持契約 (NDA) を要求することができます。

製品要件の例

UML を使用して暗号化を説明する方法を説明するために、いくつかのセキュリティ要件を持つ製品を想像してみましょう。次に、実装を提案し、UML 図を使用して実装の暗号化について説明します。

製品が Digital Encabulator for Enterprise (DEE) バージョン 1 であると想像してください。DEE は、モバイル デバイス、ラップトップ、デスクトップ コンピューターのエンド ユーザーが利用できます。セキュリティ要件は、次のすべてを行うことです。

• パスコードベースの暗号化 ( PBE ) を使用して保存データを保護します。パスコードは、エンド ユーザーが入力する秘密の値になります。
• 保護されたデータの可用性を損なうことなく、パスコードの変更をサポートします。
• エンド ユーザーがパスコードを忘れた場合のデータ復旧をサポートします。
• エンド ユーザーの知らないうちに企業によるデータ監査をサポートします。
• 暗号化には、よく知られた標準的な方法を使用してください。

• パスコードは、各エンド ユーザーがアプリをインストールするときに設定します。
• パスコード キー (PK) は、これらのパラメーターを使用して PBKDF2 (Passcode Based Key Derivation Function バージョン 2) プロセスによってパスコードから生成されます。
  - ハッシュベースのメッセージ認証コード (HMAC) 疑似ランダム関数。
  - SHA256 ハッシュ関数。
  - 20,000回の繰り返し。
• PBKDF2 入力には、パスコード ソルト (PS) 値が含まれます。PS は安全な乱数発生器 (RNG) によって生成されます。
• PS 値は、デバイスに永続的に保存されます。PK 値もパスコードも保存されません。

• アプリケーション データを中間データ暗号化キー (DEK) で保護します。DEK は、安全な RNG によって生成される長いランダム値になります。DEK の長さは 256 ビットであり、ブルート フォースによる実用的な時間内の推測を軽減します。
• PK で暗号化された DEK をデバイスの永続ストレージに保存します。DEK を永続ストレージに平文で保存しないでください。暗号化では、AES キー ラップ アルゴリズムが使用されます。
• ユーザーがパスコードを変更したら、新しい PK 値で DEK を再暗号化します。(DEK がないと、パスコードが変更されたときにすべてのアプリケーション データを再暗号化する必要があります。)

• データ復旧サービス (DRS) を提供します。
• エンド ユーザーがデバイスで DEK を生成すると、DRS はセットアップ要求 (DRS-SU) を受け取ります。DRS-SU にはユーザー ID が含まれており、ユーザーを ID プロバイダー (IDP) にリダイレクトするなど、帯域外でのユーザー認証が必要になります。
• DRS は、DRS-SU を受信すると、非対称暗号化用のキー ペアを生成します。キー ペアには、生成されてハードウェア セキュリティ モジュール (HSM) に格納される秘密キー (RIK) と、対応する公開キー (RUK) があります。RIK の長さは 2048 ビットになります。
• DRS は RUK を送り返すことで DRS-SU に応答します。
• ユーザー アプリは、RUK によって暗号化された DEK をデバイスの永続ストレージに保存します。暗号化では、PKCS1 パディングを使用した RSA アルゴリズムが使用されます。
• エンド ユーザー アプリは、復旧要求 (DRS-RY) を DRS に送信できます。DRS-RY にはユーザー識別子が含まれ、DRS-SU と同様にユーザー認証が必要であり、RUK によって暗号化された DEK が含まれます。
• DRS が DRS-RY を受信すると、HSM 内の RIK によって DEK が復号化されます。DRS は DRS-RY に DEK で応答します。

• DRS は、監査要求 (DRS-AT) を受信できます。DRS-AT には DRS-RY と同じ値が含まれ、さらに監査ユーザー ID が含まれます。監査ユーザーには承認が必要です。
• DRS-AT に対する DRS の処理と応答は、その他の点では DRS-RY の場合と同じです。

この図は、実装における基本的な暗号化機能を UML クラス図として表しています。

図は次のことを表しています。

Secure Random Number Generator はクラスです。その名前は RNG に省略されます。

• RNG インスタンスには属性 length があり、デフォルト値は 256 です。
• RNG インスタンスには、長さビットを返すパラメーターを持たない操作 getNext があります。

• Cipher インスタンスには、デフォルトで AES-GCM (ガロア/カウンター モードの高度暗号化標準) の属性、アルゴリズムがあります。
• Cipher インスタンスには、Key と Plaintext の 2 つのパラメーターを取り、Ciphertext を返す操作、encrypt があります。データ型についての詳細はありません。
• Cipher インスタンスには、Key と Ciphertext の 2 つのパラメーターを取り、Plaintext を返す操作、decrypt があります。データ型についての詳細はありません。

配置図の例

この図は、実装における暗号化リソースの保管と保護を UML 配置図として表しています。

挿入された謝罪: この図は、次の点で UML 標準から逸脱しています。

• アプリケーション データなどのアーティファクトは、ドキュメント マーカーのない長方形として表示されます。
  ドキュメント マーカーは、標準では不要なようです。たとえば、アプリケーション データが実行環境ではないことは、平らな四角形からすでに明らかです。
• RNG インスタンスなどのオブジェクトは、配置図に表示されます。
  ここで使用されているスタイル (角が直角でテキストに下線が引かれた長方形) は、UML オブジェクト図標準から取られています。
  同じインスタンスを使用して個別のオブジェクト図を描画するが、展開されたコンテキストがない場合、読者は余分な図を見る必要があります。
• 接続のラベルは、通信を正確に示しているわけではありません。代わりに、パラメーター名とその関係が表示されます。
• 非対称暗号インスタンスは、アプリケーション ランタイム メモリ環境に表示されます。これは暗号化には正しいですが、復号化には正しくありません。
  これは、図を拡張して、DRS セットアップ要求と DRS 復旧要求用に別の環境またはドキュメントを表示することで対処できる可能性があります。

• このデータは、アプリケーションによって永続的に保存されます。
  -追伸。
  - PK によって暗号化された DEK。
  - 暗号化されたアプリケーション データ。
  - RUK によって暗号化された DEK。
• アプリケーションによって他のデータが永続的に保存されることはありません。
• RIK は、DRS 内の HSM に格納されます。
• RUK は DRS によって生成されますが、DRS には保存されません。
• DEK は、RUK と PK という 2 つの異なるキーによって暗号化されて保存されます。PK 暗号化には、デフォルトの AES-GCM の代わりに AES-KW (Advanced Encryption Standard Key Wrap) アルゴリズムが使用されます。
• PS は、デフォルトの長さ 256 のランダム値です。RIK と RUK は、指定された長さ 2048 のランダム値に基づいています。

• アプリケーション データは、DEK を取得した場合にのみ、永続ストレージから取得できます。
• パスコードがわかっている場合、DEK は永続ストレージから取得できます。PS は永続ストレージにあり、PK はパスコードと PS で KDF を実行することで取得できます。
• RIK にアクセスできる場合は、永続ストレージから DEK を取得することもできます。RUK で暗号化された DEK は永続的に保存され、RIK で復号化できます。この図は、復号化を処理するために、RUK によって暗号化された DEK を DRS に送信する必要があることを示していません。

アクティビティ図の例

この図は、パスコードを設定する処理を UML アクティビティ図で表現したものです。

以下の標準要素が使用されます。

• 鍵の導出などのアクションは角が丸い。
• 角が直角のオブジェクト ノードは、キーやソルト値などの暗号化リソースを表すために使用されます。
• ピン (テキスト ラベルが付いた小さな四角形) は、アクションのパラメーターを示します。ピンは、複数のパラメーターがある場合にのみ使用されます。
  - キーと平文の 2 つがあるため、encrypt() プロセスへの入力パラメータにはピンがあります。
  - encrypt() プロセスの出力には、パラメーター ciphertext が 1 つしかないため、ピンはありません。
• 太いバーは、独立した処理の開始と終了を示します。たとえば、PS を生成する RNG getNext() は、KDF 処理のパラメータであるパスコードとは無関係です。これは完全に標準的ではないかもしれませんが、リソースからの 2 つのフローを避けることができます。

1. パスコードが入力されると処理が開始されます。
2. クラス図に示すように、安全な乱数ジェネレーター (RNG) がデフォルトの長さで実行されます。出力は、永続的に保存されるパスコード ソルト (PS) です。
3. クラス ダイアグラムに示すように、パスコードをシークレット、PS 値をソルト、既定のアルゴリズムと反復回数を使用してキー派生関数が実行されます。出力は、永続的に保存されないパスコード キー (PK) です。
4. クラス図に示すように、別の RNG がデフォルトの長さで実行されます。出力は、永続的に保存されないデータ暗号化キー (DEK) です。
5. 暗号化プロセスは、キーとして PK、平文として DEK、およびアルゴリズム AES-KW を使用して実行されます。出力は永続的に保存されます。

• データ復旧を設定します。
• パスコードを変更します。
• アプリを起動します。これには、データ暗号化キーの取得が含まれます。取得は、ユーザーが入力したパスコードからパスコード キーを再生成することによって、またはデータ回復サービスから、永続的なストレージから行うことができます。
• アプリケーションデータを保存します。

上記の例は、UML ダイアグラムを使用して暗号化を説明できることを示しています。さまざまな側面を説明するために、さまざまな種類の UML ダイアグラムを使用できます。

• クラス図は、使用されている暗号化標準とパラメーターを示しています。
• 配置図は、リソースが格納されている場所、格納されている場合、およびどのリソースがどのキーによって保護されているかを示します。
• アクティビティ図は、一連の処理を示します。オブジェクト ノードは、どのリソースが処理に関与しているかを示します。

実際のソリューションの暗号化の説明の例については、ここで公開されているホワイト ペーパーをご覧ください。
developer.vmware.com/…/MobileApplicationManagement.pdf
(UML ダイアグラムは、パスコード ベースの暗号化ダイアグラムの見出しの下にある保存データの Workspace ONE 暗号化セクションにあります。)

この記事とホワイト ペーパーの図は、draw.io ツールとしても知られる、diagrams.netツールを使用して描画されました。

統一モデリング言語 (UML) 標準の背景については、https://uml.orgWeb サイトと、Martin Fowler による UML Distilled Third Edition という書籍があります。

暗号化の標準と用語については、Jean-Philippe Aumasson 著の『Serious Cryptography』という本を参照してください。