Скрипт шифрования файлов открытым ключом OpenSSL

Архивирует папку, шифрует её открытым ключом и генерирует другой скрипт, содержащий в себе одноразовый ключ, данные и команды для расшифровки. Кроме того, скрипт может сгенерировать для вас пару RSA ключей.
Генерируем пару ключей. После этого папка folder шифруется в скрипт decrypt-folder.sh а затем расшифровывается в архив folder.tar. Из минусов отмечу то, что данные в decrypt-folder.sh хранятся в формате BASE64 – соответственно их размер увеличивается:

./encrypt-file.sh -keys public.pem private.pem
./encrypt-file.sh folder public.pem > decrypt-folder.sh
chmod +x decrypt-folder.sh
./decrypt-folder.sh private.pem > folder.tar

Запускаем:

$ ./encrypt-file.sh
Usage: ./encrypt-file.sh [directory] [public-key] > [decryption-script]
or: ./encrypt-file.sh -keys [public-key] [private-key]

#!/bin/sh if [ "x$1" = x-keys ] ; then # Generated keys should not be world-readable umask 077 PUBLICKEY="$2" PRIVATEKEY="$3" if [ x"$PRIVATEKEY" = x ] ; then echo "Usage: $0 [public-key] [private-key]" exit 1 fi # Check if files exist already for f in "$PUBLICKEY" "$PRIVATEKEY" ; do if [ -e "$f" ] ; then echo -n "File $f exists! Overwrite? (y/n) " [ `head -n 1` = 'y' ] || exit 1 fi done # Generate the keys. echo "Generating 2048-bit keys..." openssl genrsa -out "$PRIVATEKEY" -des3 2048 echo "Creating public key..." openssl rsa -in "$PRIVATEKEY" -pubout -out "$PUBLICKEY" echo "Done." exit fi # # Main script, for archiving and encrypting files. # # Read the command-line arguments. # ARCHIVEDIR="$1" PUBLICKEY="$2" if ! [ -e "$ARCHIVEDIR" -a -f "$PUBLICKEY" ] ; then echo "Usage: $0 [directory] [public-key] > [decryption-script]" echo " or: $0 -keys [public-key] [private-key]" exit 1 fi # Generate the random symmetric-key password. PASSIZE=30 if [ -c /dev/urandom ] ; then KEY=`head -c 30 /dev/urandom | openssl enc -base64` else KEY=`openssl rand -base64 30` fi export KEY # Echo the script that will decrypt the data contained at the end of the script. cat <<EOF #!/bin/sh PRIVATEKEY="\$1" if ! [ -f "\$PRIVATEKEY" ] ; then echo "Usage: \$0 [private-key] > [decrypted-archive]" exit 1 fi # Decrypt the symmetric key using the private key. AESKEY=\` \\ awk '/^#BKEY/{prn=1;next} /^#EKEY/{exit} prn==1{print}' "\$0" | \\ openssl enc -base64 -d | \\ openssl rsautl -decrypt -inkey "\$PRIVATEKEY" \` export AESKEY # Using the symmetric key, decrypt the data. awk '/^#BARC/{prn=1;next} /^#EARC/{exit} prn==1{print}' "\$0" | \\ openssl enc -aes-256-cbc -d -a -pass env:AESKEY exit #BKEY EOF # Encode the symmetric key using the public key. openssl rsautl -encrypt -inkey "$PUBLICKEY" -pubin <<EOF | openssl enc -base64 $KEY EOF echo '#EKEY' echo '#BARC' # Create and encode the archive file. cd `dirname "$ARCHIVEDIR"` tar cz `basename "$ARCHIVEDIR"` | openssl enc -aes-256-cbc -pass env:KEY -a echo '#EARC'

Предлагаю оптимизировать и допилить его до уровня повышенной параноидальности)

P.S. Кому и для чего это нужно – наглядно поясняет один из старых комментов unknown:

unknown (08/02/2013 14:08) профиль/связь <#>
комментариев: 6772 документов: 419 редакций: 3821
отпечаток ключа: ...9153691B80585959
Длинные асимметричные ключи поддерживает OpenSSL. Если вас так мучает паранойя по поводу резкого прогресса во взломе асимметрики, то шифруйте сообщения им по договорённости с получателем. По крайней мере, там это поддерживается штатно.

На страницу: 1, 2 След.

Комментарии

—	unknown (11/09/2013 22:21) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Экспортирование секретного ключа в переменные окружения? Откуда такое странное решение? Существование команды keyctl игнорируется по каким-то принципиальным соображениям?

—	*Гость* (11/09/2013 23:03) <#>

unknown
Предложите свой вариант, маэстро!;) ©

—	*Гость* (12/09/2013 01:10) <#>

> Длинные асимметричные ключи поддерживает OpenSSL. Если вас так мучает паранойя по поводу резкого прогресса во взломе асимметрики, то шифруйте сообщения им по договорённости с получателем.

GnuPG в экспертном режиме вроде позволяет использовать ключи размером и 8192 и, кажется, даже ещё в 2 раза больше. Вам этого недостаточно?

Как вы решаете проблему передачи секретного ключа получателю, если ключевая пара полностью генерится отправителем? Если есть способ непосредственно передать из рук в руки, зачем привлекать ненужные сущности типа Public Key Crypto? Почему бы не шифровать симметричным ключом, который есть у обеих сторон, сразу? Даже если хочется попараноить, то для собеседников, с которыми вы можете встретиться лично, я бы посмотрел в сторону одноразового блокнота как дополнительной меры.

—	*Гость* (12/09/2013 10:14) <#>

Подскажите пожалуйста, как переключить GPG в экспертный режим? Спасибо.

—	ressa (12/09/2013 10:30, исправлен 12/09/2013 10:31) профиль/связь <#> комментариев: 1079 документов: 58 редакций: 59

GnuPG в экспертном режиме вроде позволяет использовать ключи размером и 8192 и, кажется, даже ещё в 2 раза больше.

Ну разве что для шифрования файлов, т.к. в других случаях возникнут проблемы, особенно, если использовать мобильные приложения для работы с GnuPG. К примеру тот жe APG тупо не видит ничего, что выходит за рамки стандартной длины ключа. Почтовый клиент K-9 Mail – тоже самое.
А что там про экспертный режим? Можно ведь просто значение поменять и все:
- unsigned int nbits, min, def = DEFAULT_STD_KEYSIZE, max=4096; + unsigned int nbits, min, def = DEFAULT_STD_KEYSIZE, max=16384;

Как вы решаете проблему передачи секретного ключа получателю, если ключевая пара полностью генерится отправителем?

Можно подписывать имеющимися ключами. Проблема передачи – это другая тема. Пароль сказать одним способом (устно, обезличенно письменно, да много их), а ключ передать – по защищенным каналам связи, да тупо пошифровать его в теле письма GPG и все. Уж связка Thunderbigd+Enigmail точно не захлебнется от gpg-ключа, размером в 16384.

—	ressa (12/09/2013 14:01, исправлен 12/09/2013 14:07) профиль/связь <#> комментариев: 1079 документов: 58 редакций: 59

unknown
Предложите свой вариант, маэстро!;) ©

Присоединяюсь;) Если есть время – перепиши этот кусок, буду признателен. Я не кодер и поэтому вообще не могу понять как мне эту функцию вызвать в bash, одно дело в С или Python, но как вызвать из скрипта – хз..
Я добавил только ввод размера ключа при генерации, и то по возможности допилю:
# Generate the keys. umask 077 read KEYSIZE [[ $KEYSIZE == "" ]] && KEYSIZE=4096 echo "Generating 4096-bit keys..." openssl genrsa -out "$PRIVATEKEY" -des3 "$KEYSIZE" echo "Creating public key..." openssl rsa -in "$PRIVATEKEY" -pubout -out "$PUBLICKEY" echo "Done." exit fi
Ну и развеял свои сомнения по повду BASE64, не смотря на то, что он размер прибавляет порядка 30% – зато удобнее всего хранит любую инфу в текстовом виде.

—	ressa (12/09/2013 15:41, исправлен 12/09/2013 15:41) профиль/связь <#> комментариев: 1079 документов: 58 редакций: 59

В общем небольшие обновления скрипта:
-Добавлен ввод размера ключа, по умолчанию стоит 4096
-Комменты и echo переведены на русский
-Все танцы с /dev/urandom заменены на
PASSIZE=60 export KEY=`openssl rand -base64 $PASSIZE`

Сам скрипт:

#!/bin/bash # ./encrypt.sh -keys public.pem private.pem # ./encrypt.sh folder public.pem > decrypt-folder.sh # chmod +x decrypt-folder.sh # ./decrypt-folder.sh private.pem > folder.tar # # # $ ./encrypt.sh # Usage: ./encrypt-file.sh [directory] [public-key] > [decryption-script] # or: ./encrypt-file.sh -keys [public-key] [private-key] # if [ "x$1" = x-keys ] ; then # Сгенерированные ключи не должны быть доступны для чтения umask 077 PUBLICKEY="$2" PRIVATEKEY="$3" if [ x"$PRIVATEKEY" = x ] ; then echo "Usage: $0 [public-key] [private-key]" exit 1 fi # Проверка имеющихся ключей for f in "$PUBLICKEY" "$PRIVATEKEY" ; do if [ -e "$f" ] ; then echo -n "Ключ $f уже существует! Перезаписать? (y/n) " [ `head -n 1` = 'y' ] || exit 1 fi done # Генерация новых ключей echo "Введите размер ключа. По-умолчанию 4096" read KEYSIZE [[ $KEYSIZE == "" ]] && KEYSIZE=4096 echo "Генерация $KEYSIZE-битного ключа..." openssl genrsa -out "$PRIVATEKEY" -des3 4096 echo "Создание открытого ключа..." openssl rsa -in "$PRIVATEKEY" -pubout -out "$PUBLICKEY" echo "Завершено." exit fi # # Главный скрипт для упаковки и зашифровки файлов # # Смотрите аргументы командной строки # ARCHIVEDIR="$1" PUBLICKEY="$2" if ! [ -e "$ARCHIVEDIR" -a -f "$PUBLICKEY" ] ; then echo "Шифрование: $0 [директория] [публичный ключ] > [decryption-script.sh]" echo "Генерация ключей: $0 -keys [public.pem] [private.pem]" exit 1 fi # Генерация случайного пароля PASSIZE=60 export KEY=`openssl rand -base64 $PASSIZE` # Код, который будет расшифровывать данные, хранящиеся в выходном скрипте cat <<EOF #!/bin/sh PRIVATEKEY="\$1" if ! [ -f "\$PRIVATEKEY" ] ; then echo "Дешифрование: \$0 [private.pem] > [decrypted-archive.tar]" exit 1 fi # Расшифровка с помощью приватного ключа AESKEY=\` \\ awk '/^#BKEY/{prn=1;next} /^#EKEY/{exit} prn==1{print}' "\$0" | \\ openssl enc -base64 -d | \\ openssl rsautl -decrypt -inkey "\$PRIVATEKEY" \` export AESKEY # Использование симметричного для ключа расшифровки данных awk '/^#BARC/{prn=1;next} /^#EARC/{exit} prn==1{print}' "\$0" | \\ openssl enc -aes-256-cbc -d -a -pass env:AESKEY exit #BKEY EOF # Шифрование симметричного ключа с помощью открытого ключа openssl rsautl -encrypt -inkey "$PUBLICKEY" -pubin <<EOF | openssl enc -base64 $KEY EOF echo '#EKEY' echo '#BARC' # Создание зашифрованного архива cd `dirname "$ARCHIVEDIR"` tar cz `basename "$ARCHIVEDIR"` | openssl enc -aes-256-cbc -pass env:KEY -a echo '#EARC'

Допиливайте, кому интересно.

—	unknown (12/09/2013 23:18) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

В том своём старом коменте я это не просто так написал. Я это делал и у меня как-то работало симметричное и асимметричное шифрование в простом однострочнике, одной командой. С тех я забыл как это делается, но очень удивился, увидев этот пост с небезопасным скриптованием. Я уже подумал, что меня память подводит, но гугление выдаёт готовый пример. Всё делается через сертификаты S-MIME. Вбейте в примере генерацию ключа сертификата вместо 2048, скажем 8192 бит и всё работает без таких извращений и ненужного велосипедостроения. А S-MIME это такой же стандарт шифрования почты, как и PGP, только коммерчески ориентированный, на сертификатах. Если не использовать покупные, а генерировать свои, то можно генерировать с любым размером ключа.

Всегда удивляли люди, которые просто берут и делают, без малейшего ощущения, что так делать нельзя. Почти в любой другой области, кроме безопасности, человек, готовый показать делом, а не словом, конечно лучше, но тут как раз не тот случай :)

—	*Гость* (13/09/2013 00:00) <#>

> как переключить GPG в экспертный режим?

Добавить опцию --expert в командной строке, как бы банально это ни звучало.

> Ну разве что для шифрования файлов, т.к. в других случаях возникнут проблемы, особенно, если использовать мобильные приложения для работы с GnuPG.

Из командной строки это сработает. Если повесите команду на какую-то кнопку или хоткей, то тоже. Раз вы всё равно отказываетесь от совместимости, генеря собственные скрипты, то что вы теряете?

> К примеру тот жe APG тупо не видит ничего, что выходит за рамки стандартной длины ключа. Почтовый клиент K-9 Mail – то же самое.

Прикрепляйте шифрованный с помощью gpg файл аттачем к письму, и расшифровывайте его не встроенными средствами мейлера, а руками в командной строке, например. Раз у вас всё равно самопал, то не вижу проблемы. Юзер всегда можно скачать прикреплённый файл и руками (или скриптом) его расшифровать.

> Можно подписывать имеющимися ключами.

Вы защищаетесь от гипотетического противника, который может ломать уже имеющиеся ключи, потому что они короткие. Вы не можете защитить длинный ключ, зашифровав его коротким.

> а ключ передать – по защищенным каналам связи

Которых пока ещё нет, т.к. длинный ключ у вас, а всё остальное считается скомпрометированным. Исключение — предрасшаренный симметричный ключ-пароль, переданный заведомо безопасным способом (например, из рук в руки).

> да тупо пошифровать его в теле письма GPG и все. Уж связка Thunderbigd+Enigmail точно не захлебнется от gpg-ключа, размером в 16384.

Пошифровать что и чем? Обратите внимание на мои замечания выше. Предлагаю вам подумать над тем, что вы считаете уже взломанным, а что ещё нет, и проанализировать с этой точки зрения свою схему передачи ключа. Я не буду вдаваться в резонность вашей паранои, но хотя бы в рамках своей логики вы должны быть конситентны, а то там можно дойти до того, что приватный ключ передавать открытым текстом, выкладывая его на сайт. Кстати, даже если придерживаться вашего метода, то разумно было бы ничего не передавать, а давать всем скрипт, пусть после этого каждый сам генерит для себя ключевую пару. А сверить отпечатки потом можно любым удобным способом — например, по телефону.

> Все танцы с /dev/urandom заменены на

IMHO, лучше воспользоваться pwgen. По крайней мере, я слышал, что его автор тот же, что и писал gpg.

—	*Гость* (13/09/2013 00:05) <#>

> Я это делал и у меня как-то работало симметричное и асимметричное шифрование в простом однострочнике, одной командой.

Простенький баянистый однострочник для симметричного и (должно бы быть) бессигнатурного.

—	*Гость* (13/09/2013 00:15) <#>

> Существование команды keyctl игнорируется по каким-то принципиальным соображениям?

Unknown, если вас не затруднит, напишите, зачем нужен keyctl. Он только для управления openssl-ключами или вообще любыми? Пишут про /proc/keys почему-то ещё. Поверхностный поиск не даёт ответа, в каких случаях обычно используют keyctl (я не про технику, а про суть).

—	unknown (13/09/2013 00:35) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

>Он только для управления openssl-ключами или вообще любыми?

Любыми.

>в каких случаях обычно используют keyctl

В Debian лежат примеры использования с LUKS, хотя изначально он разрабатывался не для этого. Это вроде как единственное по-настоящему безопасное решение, когда нужно передать симметричный ключ или пароль в скрипте, между скриптами или командами, чтобы он не засветился для посторонних процессов или случайно не попал на диск.

—	*Гость* (13/09/2013 01:38) <#>

Раз зашла речь о ключах, спрошу тут. Нужно сделать так, чтобы программа могла использовать приватный ключ для каких-то операций, но при этом не могла извлечь сам ключ. Трудно ли этого добиться?

Кустарный метод для keychain и работы с ssh-ключами:

# chown USER /path/to/.ssh/*.ssh*
$ keychain ~/.ssh/*.ssh
# chown root /path/to/.ssh/*.ssh*

(в конфиге шелла прописано source ~/.keychain/`hostname`-sh). Помогут ли эти костыли от кражи приватного ssh-ключа?

—	unknown (13/09/2013 16:49) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Такие решения возможны только на уровне обфускации и игры в прятки. Принципиально это невозможно.

—	*Гость* (14/09/2013 00:27) <#>

Теперь понял, согласен. Нужно, чтобы ключ был в памяти процесса, куда юзер не может писать/читать. Реализовать это (без SELinux'а) можно, только если непосредственно с ключами будет оперировать один пользователь, а запросы на подпись/расшифрование будет слать ему другой, используя какой-нибудь IPC или обвязки. Очень удивлён, что никто ещё этого не сделал для защиты ключей. Или вам известны примеры? Цель — сделать так, чтобы кража ключей была возможна только при local root.

На страницу: 1, 2 След.

Ваша оценка документа [показать результаты]