web-dev-qa-db-ja.com

OpenSSLによる安全なバックアップ暗号化

私の知っているとおり、一般的なアドバイスは「暗号のようなものには手を触れない」です。また、バックアップデータを安全に暗号化する標準的な方法は、GnuPGを使用することです。ただし、かなり学術的な演習として、POSIXシェルから呼び出されたOpenSSLの標準ツール（つまり、dgst、enc、rsautl＆Co）でのみ機能するプロトコルについて考えたいと思います。

シナリオには、多かれ少なかれ信頼できるシステムが含まれ、そこからバックアップが作成されます。 g。メールまたはファイルサーバー。次に、100％信頼されていないストレージがあります（たとえば、クラウドストレージ、または完全に私の制御下にないバックアップサーバー）。したがって、暗号化の目的は、信頼できないストレージに保存されているデータの機密性と整合性を保護することです。この保護は、信頼できるシステムが危険にさらされた場合にも機能します-少なくとも信頼できるシステムが危険にさらされる前に保存されたデータに対して。

前述の基準を満たす必要があるプロトコルの種類を次に示します。

ステップ1：RSAキーペア

このステップは一度だけ実行する必要があります。 RSAキーペアが必要です。このキーペアは、「信頼された」システムではなく、本当に信頼されたボックス（信頼されたワークステーション、またはGPGキーリングを保持するために信頼できる場所など）で作成されます。秘密鍵はリカバリにのみ必要なので、信頼できるシステムまたは信頼できないストレージのいずれの領域にも決して入ってはなりません。キーサイズは4096ビット以上である必要があります（後で説明します）。 OpenSSLは通常、以下のコマンドによるキーの生成と分離を提供します。

編集：キーをPKCS＃8に切り替え、おそらくブルートフォース攻撃に対してより耐性があります

openssl genpkey -aes-256-cbc -algorithm RSA -pkeyopt 'rsa_keygen_bits:8192' -out private.key
openssl pkey -in private.key -out public.key -pubout

ステップ2：セッションシークレットを生成する

暗号化プロセスごとに、専用の秘密（鍵、初期化ベクトル、ソルト）が生成されます。

編集：クトゥルフのコメントに従ってソルトを削除

key=$(openssl Rand -hex 32)
iv=$(openssl Rand -hex 16)
hmacpw=$(openssl Rand -base64 48)

注意：これにより、信頼されたマシンのメモリに秘密が保護されないことがわかります。ただし、攻撃者がバックアッププロセスのメモリをスキミングできる方法でマシンにアクセスできる場合、攻撃者はおそらくこれらのシークレットによって保護されるデータにすでにアクセスしています。

ステップ3：圧縮して暗号化する

暗号化の前にデータを圧縮する必要があります。とにかく圧縮が必要なので、データを暗号化する前に圧縮することをお勧めします。

編集：クトゥルフのコメントに従ってソルトを削除

data-generator | xz -zc | openssl enc -e -aes-256-ctr -K $key -iv $iv -out message.enc

ステップ4：HMACを生成してキーをパックする

最後のステップは、暗号化したばかりのデータのHMACを生成し、暗号化に公開鍵を使用して、RSA暗号化ファイルにセッションシークレットと一緒にパックすることです。

編集：クトゥルフのコメントに従ってソルトを削除

hmac=$(openssl dgst -sha512 -hmac $hmacpw -hex message.enc | sed 's/^.*=[[:space:]]//g')
echo "${key}:${iv}:${hmacpw}:${hmac}" | openssl rsautl -inkey public.key -pubin -encrypt -out message.key

そしてここで、RSAキーがそれほど大きくなければならない理由が明らかになります。シェル文字列の16進数は、半バイトではなく、それぞれ1バイトとしてカウントされます。したがって、キー文字列のサイズは、合計で（2x32 + 2x16 + 64 + 128 + 5）= 293バイト= 2344ビットになります。

繰り返しになりますが、コマンドラインでシークレットを公開することは一般に悪い考えですが、状況によっては、攻撃者がこのシステムでプレーンテキストで入手できるデータの機密性や整合性をどのように損なうかはわかりません。プライバシーや整合性をはるかに簡単に損なう可能性があります。ただし、実際にこれを実装する場合は、名前付きパイプを使用して、シークレットがプロセスリストに表示されないようにします。

今私の質問：

  1. 私は何を取りこぼしたか？私がまだ気づいていない欠陥や潜在的な攻撃ベクトルはありますか？
  2. 秘密鍵が多かれ少なかれ信頼されたシステムに存在する必要がある場合、openssl dgst -sha512 -sign private.key -out message.sig message.encを使用して署名を作成する方が安全でしょうか？
opensslfile-encryptionprotocolshmacdesign-flaw
13
Daemotron
  1. あなたが逃したかもしれないものについての質問のために：

サーバー上のデータを暗号化した時点で、rsyncを使用してデータをバックアップに安全に同期できます。

rsync -aHSv --del --progress ~/<encrypted-data> user@remote-backup-server:/<destination-directory>./ -n

--delの使用は、リモート宛先の古いものを削除することです（すべての履歴を保持したい場合は、そのオプションを安全に削除できます）。

  1. セキュリティに関する質問：

rsyncで物事を行う利点は、一部のIPで一部のportsのみを使用してbackup server firewallを保護し、RSA Keysを使用できることです。 ~/.ssh/authorized_keys

  1. OpenSSLまたはLibreSSL？

security.stack について説明するように、その点はDigにとって興味深いかもしれないと思います

1
aurelien