SecurityDelight-コンテナイメージを暗号化するためのテクノロジー

先日、興味深いタスクが発生しました。コンテナが停止したときに、コンテナの元のデータを保護する方法を見つける必要があります（読み取り：中身を読み取ることができません）。暗号化のアイデアがすぐに頭に浮かび、私の指はGoogleで大切な言葉を入力し始めました。トピックを理解しているときに、かなり興味深い記事に出くわしました。喜んでお届けします。

コンテナイメージでデータとコードの機密を保持する

過去数年間で、クラウド業界は、仮想マシンへのモノリシックアプリケーションの展開から、アプリケーションをより小さなコンポーネント（マイクロサービス）に分割してコンテナにパッケージ化することへの大きな変化を見てきました。今日のコンテナ化の人気は、主にDockerの動作によって推進されています。Dockerは、コンテナーの背後にある主要な推進力となった会社です。Dockerは、Dockerコンテナーを構築および実行するための使いやすいツールと、配布の課題に対応するDockerコンテナーレジストリを提供しています。



コンテナ化技術の成功は、主にライフサイクルのさまざまな段階でのコンテナのセキュリティに依存します。セキュリティ上の懸念の1つは、個々のコンテナ内の脆弱性の存在です。それらを識別するために、コンテナーの作成に使用されるDevOpsパイプラインには、コンテナー内の脆弱性の可能性があるパッケージを探し、それらが見つかった場合に所有者または技術者に警告するスキャナーが追加されています。IBMCloudのVulnerabilityAdvisorは、そのようなユーティリティの例です。



セキュリティのもう1つの側面は、起動するコンテナが目的のコンテナであり、変更されていないことを確認することです。この問題は、Notaryに保存されているデジタル署名を使用することで解決されます。これにより、コンテナが変更から保護されます。Docker Notaryは、イメージ署名を格納するパブリックリポジトリの例です。 Notaryを使用すると、顧客はコンテナイメージの署名を確認して、所有者またはサービス技術者のキーで署名されてからコンテナイメージが変更されていないことを確認できます。



もう1つの潜在的なセキュリティ問題は、コンテナの分離です。名前名、cgroup、Linux機能、SELinux、AppArmor、およびSeccompプロファイルなどのLinuxランタイムセキュリティテクノロジは、実行時にコンテナプロセスを制限し、コンテナを相互に分離するのに役立ちます。



この記事では、コンテナイメージのデータとコードのプライバシーに関する依然としてホットなエンタープライズセキュリティの問題について説明します。コンテナイメージを操作する際の主なセキュリティ目標は、暗号化されたコンテナイメージの作成と配布を許可して、特定の受信者のセットのみが利用できるようにすることです。この場合、他の人がこれらの画像にアクセスできる可能性がありますが、それらを実行したり、画像内の機密データを表示したりすることはできません。コンテナの暗号化は、Rivest-Shamir-Adleman（RSA）暗号化技術、楕円曲線、対称ブロック暗号アルゴリズムであるRijndaelとしても知られるAdvanced Encryption Standard（AES）などの既存の暗号化に基づいています。

入門

この記事を最大限に活用するには、Linuxコンテナとコンテナイメージに精通し、セキュリティの基本を理解している必要があります。

暗号化とコンテナに関する関連作業

私たちの知る限り、コンテナ画像の暗号化の分野での作業はありません。ただし、ファイルシステム、ブロックデバイス、またはハードウェア暗号化によるデータプライバシーと盗難防止暗号化をサポートする多くの実装と製品があります。後者は、自己暗号化ディスクを使用して実装されます。暗号化された仮想マシンイメージもあります。



暗号化されたファイルシステムは、企業の多くのオペレーティングシステムに存在し、暗号化されたパーティションとディレクトリのマウントをサポートできます。暗号化されたファイルシステムは、暗号化されたブートドライブからの起動もサポートできます。 Linuxは、dm-encryptドライバーを使用したブロックデバイス暗号化をサポートしています。 ecryptfsは、暗号化されたファイルシステムの一例です。 Linuxで利用可能な他のファイル暗号化ソリューションオープンソース。 Windowsでは、暗号化はNTFSv3.0ファイルシステムでサポートされています。さらに、多くのメーカーが自己暗号化ディスクを作成しています。仮想マシンイメージの場合、暗号化されたディスクと同様のソリューションがあります。オープンソースのQEMUMachine（PC）EmulatorおよびVMware仮想化製品は、暗号化された仮想マシンイメージをサポートします。



データの暗号化は通常、システムがオフラインのときにデータの盗難から保護することを目的としています。関連するテクノロジーは、クライアントとDockerNotaryサーバーから提供されたキーを使用してコンテナーイメージに署名することです。 Docker Notaryサーバーは、コンテナーイメージレジストリのすぐ近くで動作します。 Dockerクライアントツールのユーザーは、コンテナイメージに署名し、DockerNotaryを介してアカウントに署名をアップロードするオプションがあります。このプロセス中に、署名は、イメージとそのバージョンへのパス名を介してコンテナーイメージにバインドされます。署名は、画像のコンテンツ全体の説明に基づいて計算されるハッシュ関数を使用して作成されます。この説明は、コンテナイメージマニフェストと呼ばれます。コンテナイメージ署名テクノロジは、コンテナイメージを不正アクセスから保護する問題を解決し、コンテナイメージの出所を特定するのに役立ちます。

構造

Dockerエコシステムは、Open Container Initiative（OCI）グループの標準を使用してコンテナーイメージフォーマットを標準化するように進化しました。OCIは、コンテナーランタイムフォーマット（runtime-spec）とコンテナーイメージフォーマット（image-spec）を制御するようになりました。チームの作業には既存のコンテナ画像形式の拡張が必要だったため、暗号化された画像をサポートするための標準の拡張を特定しました。次のセクションでは、既存のコンテナイメージと拡張フォーマットについて説明します。



トップレベルでは、コンテナは、画像マニフェストのリストであるJavaScript Object Notation（JSON）ドキュメントで構成できます。たとえば、コンテナイメージに複数のアーキテクチャまたはプラットフォームが使用されている場合、このマニフェストのリストを使用できます。マニフェストリストには、アーキテクチャとオペレーティングシステムの組み合わせごとに1つずつ、コンテナマニフェストへのリンクが含まれています。たとえば、サポートされているアーキテクチャにはamd64、arm、およびppc64leが含まれ、サポートされているオペレーティングシステムにはLinuxまたはWindowsが含まれます。マニフェストのリストの例を以下のスクリーンショットに示します







。mediaTypeフィールドは、指定されたドキュメントの正確な形式を示します。このマニフェストのリストにより、関連するドキュメントに適切なパーサーを将来拡張および選択できます。



マニフェストのリストの下のレベルがマニフェストです。マニフェストもJSONドキュメントであり、画像レイヤーへの参照の順序付きリストが含まれています。これらのリンクには、レイヤーの形式を説明するmediaTypeが含まれています。形式は、レイヤーが圧縮されているかどうか、および圧縮されている場合はその方法を記述できます。たとえば、各レベルは、Dockerfileでdockerビルドを実行するときに、ビルドの特定の段階で追加されたファイルを含む.tarファイルとして保存できます。レイヤーは、ストレージ効率を向上させるために、圧縮された.gzipファイルを使用してパックされることがよくあります。マニフェストドキュメントの例を次のスクリーンショットに示します。







示されているように、マニフェストとレイヤーは「ダイジェスト」を介して参照されます。これは通常、JSONドキュメントのsha256ハッシュ関数です。マニフェストとレイヤーは通常、ファイルシステムにファイルとして保存されます。多くの場合、ファイル名はコンテンツのハッシュ関数であり、検索と読み込みが簡単になります。このハッシュメソッドの結果は、参照されるドキュメントに小さな変更を加えると、マニフェストのリストに至るまで、それを参照するすべてのドキュメントに変更が加えられることです。



チームのプロジェクトの一環として、公開キーと対称キーを使用したハイブリッド暗号化スキームに基づいて画像暗号化を作成しました。対称キーはバルクデータ暗号化（マルチレベル暗号化に使用）に使用され、公開キーは対称キーのパッキングに使用されます。OpenPGP、JSON Web Encryption（JWE）、およびPKCS＃7の3つの異なる公開鍵暗号化テクノロジーを使用しました。

OpenPGP

OpenPGPは、電子メールメッセージの暗号化と署名に一般的に使用される暗号化および署名テクノロジです。オープンソースコミュニティは、gitリポジトリ内のソースコードのコミット（タグ）に署名するためにもよく使用します。これは、RFC480のIETFによって定義されたインターネット標準であり、以前の独自のPGPテクノロジーのオープンバージョンと見なすことができます。



OpenPGPには、RSAキー用の独自の形式があります。キーは通常、キーリングファイルに保存され、プレーンなOpenPGPキーファイルからインポートできます。 OpenPGPキーリングの最も便利な側面は、公開キーを所有者の電子メールアドレスにリンクできることです。メールアドレスで受信者のリストを選択するだけで、メッセージの複数の受信者を操作できます。受信者のリストは、それらの受信者の公開キーに表示されます。さらに、このテクノロジーを中心に信頼のWebが構築されています。多くのユーザーの公開鍵を、電子メールアドレスで並べ替えて見つけることができます。たとえば、これらのキーはgitタグの署名によく使用されます。



OpenPGP暗号化メッセージ形式を使用して、複数の受信者への一括メッセージを暗号化できます。 OpenPGPメッセージヘッダーには、受信者ごとに1つのブロックが含まれています。各ブロックには、対応する秘密鍵の復号化を試行する場所を復号化アルゴリズムに指示する64ビットの鍵識別子が含まれています。ブロック内の暗号化されたblobが復号化されると、バルクメッセージの復号化に使用できる対称キーが表示されます。各受信者の暗号化された公開鍵blobは、同じ対称鍵を示します。



同様の方法でOpenPGPを使用しましたが、この場合、OpenPGPが送信する暗号化されたメッセージはレイヤーではありません。代わりに、JSONドキュメントが含まれています。このドキュメントには、レイヤーと初期化ベクターの両方を暗号化および復号化するために使用される対称キーが含まれています。このキーをレイヤー暗号化キー（LEK）と呼び、データ暗号化キーの形式です。この方法の利点は、必要なLEKが1つだけであるということです。 LEKを使用して、1人以上の受信者のレイヤーを暗号化します。各受信者（コンテナイメージ）は異なるキータイプを持つことができ、OpenPGPキーである必要はありません。たとえば、単純なRSAキーである可能性があります。このRSAキーを使用してLEKを暗号化できる限り、異なるキータイプの複数の受信者と連携できます。

JSON Web暗号化（JWE）

JSON Web暗号化は、JWEとも呼ばれ、別のIETFインターネット標準であり、RFC7516で定義されています。これはOpenPGPよりも新しい暗号化標準であるため、より厳しい暗号化要件を満たすように設計された最新の低レベル暗号を使用します。



大規模な場合、JWEはOpenPGPと同様に機能し、メッセージのすべての受信者がアクセスできる対称キーで暗号化されたメッセージの受信者リストと一括メール送信も維持します。 JWEメッセージの受信者は、RSAキー、暗号化用の特定の楕円曲線キータイプ、対称キーなど、さまざまなタイプのキーを持つことができます。これは新しい標準であるため、PKCS＃11またはKey Management and Interoperability Protocol（KMIP）インターフェイスを使用して、TPMやハードウェアセキュリティモジュール（HSM）などのハードウェアデバイスのキーをサポートするようにJWEを拡張することも可能です。受信者がRSAキーまたは楕円曲線を持っている場合、JWEはOpenPGPと同様の方法で使用されます。将来的には、HSM内のKMIPのような対称キーをサポートするように拡張する可能性があります。

PKCS＃7

暗号化メッセージ構文（CMS）とも呼ばれるPKCS＃7は、IEFTRFC5652で定義されています。CMSに関するWikipediaによると、「あらゆる形式のデジタルデータにデジタル署名、ダイジェスト、認証、または暗号化するために使用できます。」



これは、複数の受信者とバルクメッセージの暗号化を可能にするという点で、前述の2つのテクノロジに似ています。そのため、他のテクノロジーと同じように使用しましたが、暗号化キーの証明書を提供する受信者にのみ使用しました。



前述の暗号化テクノロジーをサポートするために、マニフェストドキュメントを拡張して、次の情報を含めました。

• OpenPGP、JWE、およびPKCS＃7メッセージは、マニフェストの一部である注釈マップに格納されます。
• 指定された各レイヤーには、1つのマップが含まれます。注釈マップは基本的に、文字列をキーとして、文字列を値として持つ辞書です（キーと値のペア）。

画像の暗号化をサポートするために、次のキーを定義しました。

• org.opencontainers.image.enc.keys.openpgp
• org.opencontainers.image.enc.keys.jwe
• org.opencontainers.image.enc.keys.pkcs7

各キーによって参照される値には、対応する暗号化テクノロジの1つ以上の暗号化されたメッセージが含まれます。これらのメッセージはバイナリ形式である可能性があるため、base64でエンコードされています。暗号化されたレイヤーには、少なくとも1つのそのような注釈が必要ですが、受信者が十分な数の異なるタイプのキーを持っている場合は、すべてを含めることができます。



レイヤーがLEKで暗号化されていることを確認するために、次の例に示すように、既存のメディアタイプを「+ encrypted」サフィックスで拡張しました。

• アプリケーション/vnd.docker.image.rootfs.diff.tar+暗号化
• アプリケーション/vnd.docker.image.rootfs.diff.tar.gzip+暗号化

これらの例は、レイヤーが.tarファイルに圧縮されて暗号化されていること、または両方が.tarファイルに圧縮されて.gzipファイルに圧縮されて暗号化されていることを示しています。次のスクリーンショットは、暗号化されたレイヤーにリンクするマニフェストの例を示しています。また、暗号化されたJWEメッセージを含む注釈マップも表示されます。

対称キーを使用した階層化暗号化

LEKを使用した対称暗号化の場合、私たちのチームは、認証済み暗号化をサポートし、128ビットおよび256ビットキーのAES暗号化標準に基づく暗号を選択しました。

実装例：containerd

バリエーションをcontainerdと呼ばれる新しいコンテナランタイムプロジェクトに実装しました。 golangのソースコードは、リンクをたどることで表示できます。 Dockerデーモンはcontainerdを使用して一部のサービスを実行し、Kubernetesにはcontainerdを直接使用するためのプラグインがあります。したがって、暗号化されたコンテナイメージをサポートする拡張機能が両方に役立つことを願っています。



LEKを使用したマルチレベル暗号化の実装は、拡張の最も低いアーキテクチャレベルにあります。実装要件の1つは、数ギガバイトのボリュームレイヤーに対応する一方で、レイヤーで暗号化操作を実行するプロセスが占有するメモリの量をわずか数メガバイトに保つことでした。



Golang での認証済み暗号化アルゴリズムのサポートは、入力としてバイト配列を受け取り、暗号化（シール）または復号化（オープン）の全段階を実行して、ストリームへの追加の配列の転送と追加を防ぎます。この暗号化APIでは、レイヤー全体をメモリにロードするか、各ブロックの初期化ベクトル（IV）を変更するためのスキームを考案する必要があるため、リンクデータサポート（AEAD）でgolangの認証済み暗号化を使用しないことにしました。代わりに、ストリームでAEADをサポートする悪意のあるgolang暗号ライブラリを使用しました（ブロック）および各ブロックのIVを変更するための独自のスキームを実装します。この実装では、レイヤーを1 MBのブロックに分割し、暗号化のために1つずつ転送します。このアプローチは、認証された暗号を使用するときにメモリの量を減らします。復号化側では、反対のことを行い、Open（）関数によって返されるエラーに注意を払い、暗号化ブロックが改ざんされていないことを確認します。



対称暗号化の上に、非対称暗号化スキームはLEKと初期化ベクトル（IV）を暗号化します。暗号化スキームを追加または削除するために、各非対称暗号化実装を登録します。 Asymmetric Cryptographic Code APIがレイヤー暗号化のために呼び出されると、登録された暗号化ハンドラーを1つずつ呼び出し、受信者の公開鍵を渡します。すべての受信者キーが暗号化に使用された後、マッピングキーとして非対称暗号アルゴリズム識別子を使用し、OpenPGP、JWE、およびPKCS＃7でエンコードされたメッセージを含む値を使用して注釈マップに戻ります。各メッセージには、パックされたLEKとIVが含まれています。前のスクリーンショットに示すように、注釈マップはマニフェストドキュメントに保存されます。



すでに暗号化されている画像に受信者を追加することもできます。画像の作成者は、受信者がリストに含まれている場合は追加します。秘密鍵は、LEKおよびIVレベルを解凍するために必要な受信者リストに使用されます。次に、新しい受信者キーを使用してLEKとIVを新しいメッセージにラップし、このメッセージを注釈マップに追加します。



さまざまなタイプのキーに対して、3つのタイプの非対称暗号化スキームを使用しました。OpenPGPキーを使用してOpenPGPメッセージを暗号化します。使用しているPKCS＃7には、暗号化キーにx.509証明書が必要です。JWEは、単純なRSAキー、楕円曲線、対称キーなど、他のすべてのキータイプを処理します。KMIPサーバーによって管理されるキーを使用した暗号化操作を可能にするJWEの拡張機能のプロトタイプを作成しました。



containerdランタイムには、それと対話するためのctrクライアントツールが含まれています。 ctrを拡張して、変更のテストを可能にし、コンテナユーザーにアクセスを提供しました。 ctrは、イメージレジストリをフェッチして送信するなど、イメージ操作をサポートするサブコマンドをすでに実装しています。



イメージを暗号化し、特定のキーセットを使用して特定のアーキテクチャの特定のレイヤーの暗号化を有効にする機能を追加することにより、このサブコマンドを拡張しました。このアプローチにより、ユーザーは機密データを含むレイヤーのみを暗号化し、他のレイヤーは暗号化しないままにすることができます。後者は重複排除できますが、暗号化されたレイヤーではほとんど不可能です。



同様に、個々のアーキテクチャの個々のレイヤーを解読できます。各レイヤーの暗号化ステータスを表示し、それに使用される暗号化テクノロジーを表示するlayerinfoサブコマンドを追加しました。 OpenPGPの場合、復号化に必要なキーIDを表示したり、キーリングを使用してそれらを受信者の電子メールアドレスに変換したりすることもできます。



さらに、コンテナイメージをエクスポートおよびインポートできます。エクスポート時のレイヤー暗号化とインポート時の復号化のサポートを実装しました。レイヤーを復号化してコンテナーのrootfsファイルシステムを作成しても、暗号化されたレイヤーとそのマニフェストなどの元のメタデータファイルは保持されます。このアプローチにより、ユーザーが暗号化されたイメージでコンテナーを開始するときに、暗号化されたイメージをエクスポートし、許可チェックを実行できます。



プレーンな（暗号化されていない）イメージがレジストリから取得されると、自動的に解凍および解凍されるため、コンテナをすぐに作成できます。暗号化された画像を簡単に作成できるように、解凍チームに秘密鍵を渡して、解凍する前にレイヤーを復号化できるようにすることをお勧めします。画像が複数のキーで暗号化されている場合、複数のキーをプルコマンドに渡すことができます。この転送もサポートされています。レジストリから暗号化された画像を正常に抽出した後、containerdにアクセスできる人は誰でも、画像からコンテナを作成できます。ユーザーがコンテナイメージを使用する権限を持っていることを確認するために、コンテナの復号化に使用する秘密鍵を提供することをお勧めします。キーを使用して、ユーザーの承認、暗号化された各レベルのLEKの復号化に使用できるかどうかを確認し、これが確認された場合は、コンテナーの起動を許可します。

containerdを使用した暗号化のステップバイステップガイド

このセクションでは、コマンドラインでctrを使用してcontainderdで適用される暗号化手順を示します。コンテナイメージを暗号化および復号化する方法を示します。



まず、サブプロジェクトであり、コンテナイメージを暗号化/復号化できるgit containerd / imgcryptリポジトリのクローンを作成する必要があります。次に、containerdをビルドして実行する必要があります。これらの手順を完了するには、golang開発環境がどのように設定されているかを知る必要があります



。imgcryptにはコンテナバージョン1.3以降が必要です。



imgcryptをビルドしてインストールします。

# make
# sudo make install

以下の例に示す構成ファイルを使用してcontainerdを実行します。containerdでの競合を回避するには、ディレクトリに/ tmpディレクトリを使用します。また、ソースからコンテナバージョン1.3をビルドしますが、インストールしないでください。

# cat config.toml
disable_plugins = ["cri"]
root = "/tmp/var/lib/containerd"
state = "/tmp/run/containerd"
[grpc]
  address = "/tmp/run/containerd/containerd.sock"
  uid = 0
  gid = 0
[stream_processors]
    [stream_processors."io.containerd.ocicrypt.decoder.v1.tar.gzip"]
        accepts = ["application/vnd.oci.image.layer.v1.tar+gzip+encrypted"]
        returns = "application/vnd.oci.image.layer.v1.tar+gzip"
        path = "/usr/local/bin/ctd-decoder"
    [stream_processors."io.containerd.ocicrypt.decoder.v1.tar"]
        accepts = ["application/vnd.oci.image.layer.v1.tar+encrypted"]
        returns = "application/vnd.oci.image.layer.v1.tar"
        path = "/usr/local/bin/ctd-decoder"
# sudo ~/src/github.com/containerd/containerd/bin/containerd -c config.toml

opensslコマンドラインツールを使用してRSAキーペアを作成し、イメージを暗号化します。

# openssl genrsa --out mykey.pem
Generating RSA private key, 2048 bit long modulus (2 primes)
...............................................+++++
............................+++++
e is 65537 (0x010001)
# openssl rsa -in mykey.pem -pubout -out mypubkey.pem
writing RSA key
# sudo chmod 0666 /tmp/run/containerd/containerd.sock
# CTR="/usr/local/bin/ctr-enc -a /tmp/run/containerd/containerd.sock"
# $CTR images pull --all-platforms docker.io/library/bash:latest
[...]
# $CTR images layerinfo --platform linux/amd64 docker.io/library/bash:latest
   #                                                                    DIGEST      PLATFORM      SIZE   ENCRYPTION   RECIPIENTS
   0   sha256:9d48c3bd43c520dc2784e868a780e976b207cbf493eaff8c6596eb871cbd9609   linux/amd64   2789669                          
   1   sha256:7dd01fd971d4ec7058c5636a505327b24e5fc8bd7f62816a9d518472bd9b15c0   linux/amd64   3174665                          
   2   sha256:691cfbca522787898c8b37f063dd20e5524e7d103e1a3b298bd2e2b8da54faf5   linux/amd64       340                          
# $CTR images encrypt --recipient jwe:mypubkey.pem --platform linux/amd64 docker.io/library/bash:latest bash.enc:latest
Encrypting docker.io/library/bash:latest to bash.enc:latest
$ $CTR images layerinfo --platform linux/amd64 bash.enc:latest
   #                                                                    DIGEST      PLATFORM      SIZE   ENCRYPTION   RECIPIENTS
   0   sha256:360be141b01f69b25427a9085b36ba8ad7d7a335449013fa6b32c1ecb894ab5b   linux/amd64   2789669          jwe        [jwe]
   1   sha256:ac601e66cdd275ee0e10afead03a2722e153a60982122d2d369880ea54fe82f8   linux/amd64   3174665          jwe        [jwe]
   2   sha256:41e47064fd00424e328915ad2f7f716bd86ea2d0d8315edaf33ecaa6a2464530   linux/amd64       340          jwe        [jwe]

ローカルイメージレジストリを起動して、暗号化されたイメージをアップロードできるようにします。暗号化されたコンテナイメージを受信するには、最新のレジストリバージョンが必要です。

# docker pull registry:latest
# docker run -d -p 5000:5000 --restart=always --name registry registry

暗号化されたイメージをローカルレジストリにアップロードし、ctr-encを使用して抽出してから、イメージを実行します。

# $CTR images tag bash.enc:latest localhost:5000/bash.enc:latest
# $CTR images push localhost:5000/bash.enc:latest
# $CTR images rm localhost:5000/bash.enc:latest bash.enc:latest
# $CTR images pull localhost:5000/bash.enc:latest
# sudo $CTR run --rm localhost:5000/bash.enc:latest test echo 'Hello World!'
ctr: you are not authorized to use this image: missing private key needed for decryption
# sudo $CTR run --rm --key mykey.pem localhost:5000/bash.enc:latest test echo 'Hello World!'
Hello World!

結論

コンテナイメージの暗号化は、セキュリティを強化するための優れた機能であり、データの機密性と保管場所でのコンテナイメージの整合性を保証します。提案された技術は、公に利用可能なRSA、楕円曲線、およびAES暗号化技術に基づいています。OpenPGP、JWE、PKCS＃7などの高レベルの暗号化スキームにキーを適用します。OpenPGPの操作方法を知っている場合は、OpenPGP受信者のコンテナイメージを電子メールアドレスを使用して暗号化できますが、JWEのように暗号化には単純なRSAキーと楕円曲線が使用されます。