GT.Mは、暗号の選択を可能にするプラグイン・アーキテクチャでデータベースの暗号化を実装します。GT.Mプロセスに静的または動的にリンクされたコードは、外部呼び出しに使用されるコードの要件を満たしている必要があります。GT.Mディストリビューションには、いくつかの一般的なパッケージとライブラリにインタフェースするリファレンス実装が含まれています。そのままのリファレンス実装を使用することができますが、暗号とパッケージの選択はあなたのものであり、FISは特定のパッケージの推奨もサポートもしていません。

GT.Mデータベース・ファイルには、いくつかの部分が含まれています：

暗号化されたデータベースでは、GT.Mはデータベース内のインデックスとデータ・レコードのみを暗号化します。ファイル・ヘッダー、ビットマップ、ブロック・ヘッダーは暗号化されません。つまり、データベース構造に関する情報は暗号化されません。これは、ジャーナリングのオン/オフを切り替えるなどのシステム管理操作では、データベース・ファイルに暗号化キーを必要としないことを意味します。他のもの、例えば、MUPIP EXTRACTは、そうです。

ジャーナル・ファイルには、before-image レコード、更新レコード、after-image レコード、トランザクション・マーカ、プロセス・レコードなどの構造情報などのデータ・レコードが含まれます。再度、before-imageレコード、更新レコード、after-imageレコード、データを含むレコードだけ暗号化されます。構造情報を含むレコードはクリアテキストのままです。

暗号化の対象となるレコードは、文書内でまとめてデータ・レコードと呼ばれます。

パフォーマンスのために、対称暗号を使用してデータレコードを暗号化および復号化します。非対称暗号は、ディスクに格納された対称暗号鍵を保護するために参照実装によって使用されます。パスワードは、ディスク上のキーリングに格納されている秘密キーを保護するために使用されます。次の図は、GNU Privacy Guard（GPG）を使用して暗号を提供するリファレンス実装のGT.Mデータベース暗号化の概要を示しています。

リファレンス実装では、ディスク上のパスワードで保護されたキーリングに、非対称暗号の秘密キーが含まれています。ディスク上のキーリングにアクセスして秘密キーを取得するには、パスワードが必要です。パスワードの取得は、次の3つの方法のいずれかで行われます：

GNOMEやKDEなどのグラフィカル・ユーザー・インターフェイスでは、GPGキーリングパスワードの入力を求められたときに検出し、ターミナル・インターフェイスの代わりにグラフィカル・インターフェイスを使用することがあります。$DISPLAY環境変数の設定を解除するか、X フォーワードを無効にするlocalhostへのssh接続を使用すると、この動作を無効にすることができます。グラフィカル・ユーザー・インターフェイスのマニュアルを参照してください。

Jobコマンドを有効にするために、ディスク上のキーリングのパスワードは、プロセスの環境変数 $gtm_passwd に存在し、親プロセスから子プロセスに渡すことができます。たとえば、プロダクションのサポート目的でFISに提出された環境をダンプする際に、パスワードが誤って漏れるのを防ぐために、製品サポートのためにFISに提出された環境のダンプでは、環境内のパスワードは、プロセスが実行されているシステム上のプロセスで利用できる情報を使用して他のシステムでは利用できない情報を使用して難読化されます。

$gtm_passwd は、子プロセスが親からパスワードを受け取る唯一の方法です。親プロセスが $gtm_passwd を子プロセスに渡したり、間違ったパスワードを渡したりしない場合、入力デバイスへのアクセス権を持たない子プロセスはほとんどエラーが発生し、エラーを終了して終了することができます。

環境内の難読化されたパスワードは、他のGT.Mプロセス（MUPIPおよびDSE）にパスワードを提供できる唯一の方法です。暗号化されたデータベースまたはジャーナルファイルに遭遇し、環境内のディスク上のキーリングへの難読化されたパスワードがない場合、次のようなエラーメッセージを出して終了します： 「 GTM-E-CRYPTINIT、暗号化ライブラリの初期化中にエラーが発生しました。環境変数 gtm_passwd が空文字列に設定されています。パスワード・プロンプトはユーティリティに許可されていません 。」$gtm_passwd に難読化されたパスワードをMUPIPとDSEプロセスに提供するには、少なくとも2つの方法があります：

次の図は、ディスク上のキーリングのパスワードの取得を示しています。エラー（たとえば、間違ったパスワードの入力など）がすぐには発生しないことに注意してください。たとえば、データへのアクセスを試みるまでDSEは暗号化キーを必要としません（ファイルヘッダーは暗号化されないため、キーは必要ありません）。

リファレンス実装では、ユーザーごとにマスター・キー・ファイルを使用して、データベースまたはジャーナルファイルごとに対称キーを取得します。環境変数 $gtm_dbkeys は、マスター・キー・ファイルを指定します。$gtm_dbkeys がファイルを指す場合、それはマスター・キー・ファイルです。ディレクトリを指している場合、そのディレクトリのファイル .gtm_dbkeys はマスター・キー・ファイル（$gtm_dbkeys/.gtm_dbkeys）です。環境変数が定義されていない場合、関数はキー・ファイル ~/.gtm_dbkeys（つまり、プロセスのuseridのホームディレクトリ）を探します。マスターキーファイルには、次のセクションが含まれています：

dat database_filename

key key_filename

database_filename はデータベースファイルの名前です、例： /var/xyzapp/gbls/accounts.dat。 key_filename は、公開キーで暗号化された対称キーを含むキーファイルの名前です、例： /home/sylvia/dbkeys/accounts.key

キー・ファイルはテキストファイルで、ファックスやEメールで送信することもできます。非対称暗号化で保護されているため、安全でないチャネルで送信することができます。以下で説明するように、同じdatabase_filenameは、マスターキーファイルで複数回発生する可能性があります。.

各key_filename では、GT.Mプロセス（MUMPS、MUPIP、またはDSE）は、ディスク上のキーリングとマスター・キー・ファイルからメモリ・キー・リングを構築します。メモリ・キー・リングには、各要素がファイル名、対称暗号キー、およびその対称暗号キーの暗号ハッシュで構成される要素のリストが含まれています。ディスク上のキーリングから取得した秘密キーを使用して、GT.Mはマスター・キー・ファイルが指すキーファイルから対称キーを取得します。

データベース・ファイルとジャーナル・ファイルのヘッダーには、そのファイルに使用されている暗号化キーとアルゴリズムの暗号化ハッシュが含まれています。ファイルを開くとき、GT.Mはメモリ・キー・リングのキーを使用します。メモリ・キー・リングのハッシュはヘッダーと一致します。キーリングの database_filename は無視されます。古いキーは、不要になるまで削除する必要はありません（たとえば、復元されたデータベースのバックアップコピーにアクセスするために古いキーが必要な場合があります）。同じdatabase_filenameをマスター・キー・ファイルで複数回使用できるようにすることで、アプリケーションの複数のインスタンスに1つのマスター・キー・ファイルを使用することもできます。これにより、ファイルの名前が変更されたり、別の場所からコピーされたりしても、ファイルの正しいキーが常に使用されます。正しいキーはメモリ・キー・リングで使用できる必要があります。そのようなキーが存在しない場合、GT.M は、CRYPTKEYFETCHFAILEDエラーをトリガーします。

MUPIP CREATE の場合のみ、GT.Mは、キーリングの database_filename に依存します。MUPIP CREATEは、正しいキーの暗号ハッシュを計算してデータベース・ファイル・ヘッダーに格納します。同じ database_filename がマスター・キー・ファイル（したがってメモリ・キー・リング）に複数回出現する場合、MUPIP CREATEは、マスター・キー・ファイル内でその database_filename が最後に出現したときに関連付けられたkey_filenameを使用します。

これは次の図で示されています：

先に説明したように、プロセスはそのキーをデータベースまたはジャーナル・ファイル・ヘッダーのハッシュと一致するそのメモリー・キー・リングで使用します。ファイル名はチェックされません。MUPIP CREATE は、データベース作成時にキーのハッシュ値を計算し、それをデータベース・ファイル・ヘッダーに書き込みます。GT.Mは、暗号化されたデータベース・ファイル用の新しいジャーナル・ファイルを作成すると、データベース・ファイル・ヘッダーからジャーナル・ファイル・ヘッダーにハッシュをコピーします。同様に、MUPIP EXTRACT -FORMAT=BINARY は、暗号化された抽出ファイルにデータベース・ファイル・ハッシュを格納します。実際には、複数のデータベース・ファイルから抽出が得られるので、抽出された各暗号化データベースのファイル・ヘッダから抽出されます。抽出内の各セクションを処理するとき、MUPIP LOADはその抽出キーの各セクションのハッシュと一致するそのキーをメモリキーリングで使用します。

ディスク上では、データベースとジャーナルファイルは常に暗号化されます。- GT.Mは、暗号化されていないデータを暗号化されたデータベースやジャーナルファイルに書き込むことはありません。GT.Mは、ディスクからデータレコードを読み取るときに復号化を使用し、ディスクにデータ・レコードを書き込むときに暗号化を使用します。

暗号化されたデータベースでは、割り当てられるグローバル・バッファの数は自動的に2倍になります。例えば、データベース・ファイルのヘッダーに 2000個のグローバル・バッファが指定されている場合、ファイルが開かれたときに、GT.Mが4000個のグローバル・バッファを自動的に割り当てます。グローバル・バッファはペアで使用されます： 一方のグローバルバッファには暗号化されたデータベース・ブロックのコピーがディスク上に存在し、他方のバッファには暗号化されていないバージョンのコピーがあります。共有メモリー内の制御構造（ロック・スペースおよびジャーナル・バッファーを含む）のサイズは変更されません。したがって、暗号化されたデータベースを使用する場合は、メモリと共有メモリの使用量を適切に調整する必要があります： 開いているデータベースファイルごとに、共有メモリの使用量はグローバル・バッファの数とブロックサイズを掛け合わせます。たとえば、データベース・ファイルのブロックサイズが 2048 のグローバルバッファを持つ4KBで、暗号化されていない場合、そのデータベース・ファイルの共有メモリ・セグメントが9MBを占める場合、ファイルが暗号化されるときに17MBを占有します。ご使用のオペレーティング・システムによっては、システム構成およびチューニング・パラメーターを変更する必要があります。グローバルバッファ以外にも、暗号化によるメモリ使用量の変更はありません。

暗号化されたデータベースは、暗号化と復号化のために追加のCPUリソースを消費します。選択されたアルゴリズム、アプリケーションパターンおよびハードウェア構成の詳細な知識がなければ、これが相当なものかどうか、アプリケーションのスループットが影響を受けるかどうかは予測できません。可能な限り、FISはGT.Mデータベース暗号化を設計して、追加のCPUリソースがソフトウェアクリティカルセクション外で消費されるようにしました。少なくとも、CPUリソースが不足していないコンピュータシステムでは、アプリケーション・スループットに対する暗号化の影響を最小限に抑えることが目的です。暗号化がシステムで実行されているときに、実際には運用環境を正確に反映したテスト環境を使用して、アプリケーションに及ぼす実際の影響を判断する必要があります。