Security in Plan9 / Безопасность в Plan9: Chapter 1

<pre> /* client */
int
p9auth(int fd)
{
AuthInfo *ai;
ai = auth_proxy(fd, auth_getkey, "proto=p9any role=client");
if(ai == NULL)
return -1;
/* start cpu protocol here */
}
/* server */
int
srvp9auth(int fd, char *user)
{
AuthInfo *ai;
ai = auth_proxy(fd, NULL, "proto=p9any role=server");
if(ai == NULL)
return -1;
/* set user id for server process */
if(auth_chuid(ai, NULL) &lt; 0)
return -1;
/* start cpu protocol here */
}
</pre>

rapidfx 28.04.09 в 16:20

Auth_chuid инкапсулирует взаимодействие для изменения пользовательского idб при помощи файлов caphash и capuse на стороне сервера. Отметьте, что даже если клиентский процесс может зарпосить у пользователя новый ключ, при помощи auth_getkey, компьютер-сервер предположительно разделяемая машина в псевдо-пользователем в качестве владельца хоста, установит получающую ключи функцию в NULL.

5. Защищенное хранилище / Безопасное хранилище

rapidfx 28.04.09 в 16:26

Factotum хранит ключи в пямяти не сохраняющий информацию при выключении электропитания, которая должна каким-то образом инициализироваться во время загурзки компьютера. Поэтому factotum должен дополнительно с постоянного носителя, например флоппи-диска содержащего ключевой файл скопировать его в /mnt/factotum/ctl во время загрузки. Но съемные носители неудобны для перевозки и подвержены риску кражи. Ключи должны храниться в зашифрованной файловой системе с разделяемым доступом, но только если эти ключи не необходимы для аутентификации файловой системы в первую очередь. Даже если ключи зашифрованы пользовательским паролем, вор может добиться успехапроведя атаку по словарю. Другие риски локального хранилища - потеря содержимого в случае механической порчи или севших батарей. Поэтому для удобства и безопасности мы предоставляем в сети сервер secstore (secure store - безопасное хранилище) которое хранит для каждого пользователя список его первичных ключей, ключевой файл.

rapidfx 28.04.09 в 16:41

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

rapidfx 28.04.09 в 17:23

Криптографическая технология которая позволяет secstore сформировать зашифрованный обмен ключами называется PAK [Boyk00], аналогична EKE [Bell93], SRP [Wu98], или SPEKE [Jabl]. PAK была отобрана потому что она по силе эквивалентна алгоритму Diffie-Hellman; едва уловимые утечки в ранних протоколах ключей обмена побудили нас подойти к этому вопросу со всей тщательностью. В общих чертах, протокол PAK есть:
C->S: C,gxH

rapidfx 28.04.09 в 17:28

S->C: S,gy,hash(gxy,C,S)

rapidfx 28.04.09 в 17:28

C->S: hash(gxy,S,C)

rapidfx 28.04.09 в 17:28

где H предварительно известный пароль обоим и клиенту C и серверу S. Есть несколько вариантов PAK,все они описаны документально с доказательствами их криптографических свойств. В помощь тем кто реализует алгоритмы, мы отделили их описание в раздел Приложение. Open source лицензия Plan 9 предоставляет для использования патент Lucent для зашифрованного обмена ключами.

rapidfx 28.04.09 в 18:07

Дальнейший уровень обороны от кражи паролей, мы обеспечиваем (при шифровании канала C->S) сообщения что они проверены на RADIUS-сервере, таком как цифровая форма аппаратного ключа (token) [RFC2138]. Он обеспечивает двух-факторную аутентификацию (т.е. при участии двух сторон), которая будет успешной только в случае, если удасться обмануть двух независимых администраторов одной из атак социальной инженерии.

rapidfx 28.04.09 в 18:14

Файл ключей хранится на сервере зашифрованный по алгоритму AES (Rijndael) с использованием CBC с 10-байтовым вектором инициализации и замыкающим аутентификационным подкладкой (padding). Все это невидимо для пользователя secstore. По сути, это невидимо и для сервера secstore, если для AES стандартизируют новый формат шифрования, он может быть реальзован клиентом без изменения сервера. Хранилище secstore преднамеренно не сохраняется в резервных копиях, пользователь может использовать более одного secstore или хранить файл ключей на съемном носителе. Пользовательский пароль хэшируется создавая H, для использования в протоколе PAK; другой хэш пароля как ключ шифрования файла. И наконец, существует команда (внутри аутентифицированного, зашифрованного канала между клиентом и secstore) для изменения пароляпутем посылки нового H; для логичности, клиентский процесс должен в то же самое время извлечь и перекодировать все файлы.

rapidfx 28.04.09 в 18:25

Когда factotum запускается, он соединяется с локальным secstore и проеряет имеет ли пользователь аккаунт. Если это так, он спрашивает пользовательский пароль от secstore и извлекает из него файл ключей. Протокол PAK гарантирует взаимную аутентификацию и предотвращает атаку по словарю, или перехват пароля при прослушивании соединения, или утечку пароля при активном внедрении. Пароли сохраненные в файле ключеймогут быть длинными строками случайных символов предназначенные для простых протоколов вызов/отклик. Следовательно, пользователю нужно запомнить единственный, слабый пароль для разрешения сильной централизованной аутентификации оставляя без изменения наследие из программ разбросанных между несколькими доменами аутентификации.

6. Транспортный уровень безопасности / TLS

rapidfx 29.04.09 в 05:21

Во время разработки операционныой системы Plan 9, предполагалось что она будет использоваться в элементах сети которые подвержены прямым атакам, не защищены файерволами или VPN, мы искали гарантии того что все приложения каналы со взаимной аутентификацией и шифрованием. Для этого за основу было взято TLS 1.0 [RFC2246]. (TLS 1.0 это практически то же само, что и SSL 3.0, и наше программное обеспечение проектировалось для взаимодействия с обоими стандартами.)

rapidfx 29.04.09 в 05:27

TLS определяет протокол уровня записей для целостности сообщения и секретности посредством подписывания сообщения и шифрования разделяемым ключом. Мы реализовали эту службу как устройство ядра, хотя они и будет исполняться со слегка завышенными затратами при помощи вызова отдельной программы. Библиотечный интерфейс к TLS устройству ядра:

rapidfx 29.04.09 в 05:37

int pushtls(int fd, char *hashalg, char *cryptalg, int isclient, char *secret, char *dir);

rapidfx 29.04.09 в 05:27

Передаются файловый дескриптор, имена дайджеста и алгоритма шифрования, и разделяемый секрет, pushtls возвращает новый файловый дескриптор для зашифрованного соединения. (Последний аргумент - dir принимает название директории в устройстве TLS которое ассоциируется с новым соединением.) Функция названа по аналогии с операцией "push" поддерживаемой системой потокового ввода-вывода в Research Unix и двух первых редакциях Plan 9. Поскольку добаление шифрования это просто замена одного фалового дескриптора на другой, добавление шифрования в обчный сетевой сервис становится тривиальным.

rapidfx 29.04.09 в 05:45

В Plan 9 протокол аутентификации с разделяемым ключом устанавливается с взаимным 56-битным паролем. Родные сетевые сервисы Plan 9 такие как cpu и exportfs используют эти протоколы для аутентификации и затем вызывают pushtls с общим секретом.

rapidfx 29.04.09 в 05:49

Над уровнем записей, TLS определяет протокол рукопожатия использующий публичные ключи для установления сессионного секрета. Этот протокол широко используется с HTTP и IMAP4 для предоставления серверной аутентификации, через клиентский сертификат дающий возможность произвести взаимную аутентификацию. Библиотечная функция int tlsClient(int fd, TLSconn *conn)

rapidfx 29.04.09 в 05:52

обслуживает начальное рукопожатие и возвращяет результат pushtls. По возвращении она заполняет структуру conn сессионным ID и сертификатом X.509 пердставленным сервером, но не прикладывает усилий для проверки этого сертификата. Хотя в первоначальном дизайне намеревались работать с сертификатами X.509 в инфрастуктуре с публичными ключами, дальнейшее равертывание затягивалось и было проблематичным, так что мы усвоили простую политику простого использования сертификатов X.509 как представления публичного ключа, в зависимости от локально администрируемой директории с отпечатками SHA1 позволяющим приложениям решить какому публичному ключу доверять и с какой целью.

7. Дальнейшая работа и дискуссии

rapidfx 29.04.09 в 06:02

Kerberos, одна из ранних распределенных систем аутентификации, хранит набот аутентификационных тикетов во временном файле, называемом кэшем тикетов. Кэш тикетов защищен правами файловой системы Unix. Переменная окружения содержит имя файла кэша тикетов, делая возможным разным кэшам тикетов участвовать в обновременных разных сессиях. Пользователь авторизуется пибирая его или ее пароль Kerberos. программа login пользуется паролем Kerberos для получения временного тикета - дарственный тикет, и затем забывает пароль. Другое приложение может воспользоваться дарственным тикетом для подписывания своих тикетов в защиту пользователя на время сессии. Кэш тикетов разблокируется всякий раз когда требуется аутентификация и пользователь набирает пароль.

rapidfx 29.04.09 в 06:19

Разработчики SSH развили эту идею дальше, заменив временный файл на именованные сокеты Unix соединенные с программой уровня пользователя, названную агентом. Когда агент запускаетя и инициализируется одиним или более приватным ключом RSA, клиент SSH может использовать его для осуществления аутентификации RSA в своих нуждах. При отсутствии агента, клиент SSH обычно считывает ключи RSA с зашифрованного файла или применяет аутентификацию основанную на вводе пароля, обе они запрашивают ключевую фразу когда возникает потребность в аутентификации [Ylon96]. Самоподписанная файловая система (self-certifying file system) SFS использует похожий агент [Kami00], ограничения использования ключей клиентской аутентификации но также и для проверки публичных ключей сервера [Mazi99].

rapidfx 29.04.09 в 19:38

Factotum является логическим продолжателем этой эволюции, заменяя программно зависимые агенты SSH или SFS общим агентом способным обслуживать широкий спектр программ. При наличии одного агента для всех программ отпадает поребность иметь одного агента на каждую программу. Также это дает самим программам быть протоколонезависимым, так что, например, одна может быть построена по типу SSH и пользоваться к любым протоколом который поддерживает factotum, без того чтобы программа хоть что-нибудь о протоколах. Тардиционно каждая программа нуждалась в реализации каждого протокола аутентификации для себя, и проблему кодирования O(n2) factotum сократил до O(n).

rapidfx 29.04.09 в 19:39

Предыдущая работа над агентом была сосредоточена на его использовании в клиентской аутентификации с серверами. Посмотрев в другом направлении, подключаемый модуль аутентификации (PAM) от Sun Microsystem явился ранней попыткой предоставить общий аутентификационный механизм для Unix-подобных операционных систем [Sama96]. Без центра авторизации как в случае с PAM системные политики были связаны с различными реализациями сертевых служб. Например, в типичной Unix-системе, если системынй администратор решил не пользоваться чисто-текстовыми паролями для аутентификации целый набор конфигурационых файлов необходимо было отредактировать -- rlogind, telnetd, ftpd, sshd, и т.д. PAM решал проблемы скрывая детали данного механизма аутентификации за обычным библиотечным интерфейсом. Управляемый единственным системным конфигурационным файлом, приложение выбирало особый механизм аутентификации динамически загружая подходящую разделяемую библиотеку. PAM широко используется в Sun Solaris и некоторых дистрибутивах Linux.

rapidfx 29.04.09 в 19:39

Factotum добивается тех же целей применяя подход с агентом. Factotum является единственным процессом который нуждается в способностях создавать, так чтобы все сетевые серверы могли запускаться как недоверные пользователи (Plan 9 none или Unix nobody), которые значительно снижают ущерб если сервер бажный или скомпрометирован. Фактически, если factotum будет реализован в среде Unix, c аналогом с утройстваcapability Plan9, уязвимым программам типа su и login не нужно будет устанавливать setuid бит.

rapidfx 29.04.09 в 19:39

Некоторые другие системы, такие как Password Safe [Schn], хранят многочисленные пароли в зашифрованном файле, так что пользователю нужно запомнить единственный пароль. Наше решение secstore отличается от него, помещая хранилище в труднодоступное место в сети, так что зашифрованный файл меньне подвержен риску быть украденным для последующей атаки по словарю и так же он доступен когда пользователь работает с несколькими компьютерами. В отличии от системы Microsoft Passport [Micr] хранящейудостоверения в сети, но сосредоточены на одной исключительно значимой цели. Важное значение Passport состоит в установлении доверительных отношений с олайн-торговлей, выходящей за пределы нашего рассмотрения. Архитектура secstore в основном идентична архитектуре Perlman and Kaufman [Perl99] однако содержит новую технологию EKE. Подобно им, мы избрали защиту в основном от внешних атак на secstore; для дополнительной защиты файлов на сервере по желанию могут применяться распределенные техники [Ford00].

rapidfx 29.04.09 в 19:40

Мы сделали осознанный выбор помещая шифрование, целостность сообщений и управление ключами на уровень приложений (TLS, лежит на уровне выше 4), вместо того чтобы разместить на 3-м уровне, как в IPsec. Это привело к упрощению структуры сетевого стека, легкой интеграции с приложениями и что наиболее важно, легкому сетевому администрированию, как только мы обнаружили какие приложения ведут себя непристойно по номерам TCP портов. TLS страдает (относительно IPsec) от возможности забыть TCP Reset, но мы чувствовали, что это будет адекватная сделка по рандомизации числа последовательности TCP. В стравнении с другими библиотеками TLS, Plan 9 не требует изменения приложений для смены вызовов write на sslwrite, а просто добавление нескольких новых строк кода на старте [Resc01].Мы сделали осознанный выбор помещая шифрование, целостность сообщений и управление ключами на уровень приложений (TLS, лежит на уровне выше 4), вместо того чтобы разместить на 3-м уровне, как в IPsec. Это привело к упрощению структуры сетевого стека, легкой интеграции с приложениями и что наиболее важно, легкому сетевому администрированию, как только мы обнаружили какие приложения ведут себя непристойно по номерам TCP портов. TLS страдает (относительно IPsec) от возможности забыть TCP Reset, но мы чувствовали, что это будет адекватная сделка по рандомизации числа последовательности TCP. В стравнении с другими библиотеками TLS, Plan 9 не требует изменения приложений для смены вызовов write на sslwrite, а просто добавление нескольких новых строк кода на старте [Resc01].

8. Заключение

rapidfx 29.04.09 в 19:40

Написание безопасного кода сложная задача. Атаки на стек, ошибки в логике, баги в компиляторе и операционных системах, каждая делает возможным для атакующего нарушить последовательность выполнения в сервисе. Если процесс сервера имеет преимущества привелегированного пользователя, такого как root в Unix, тогда это на руку нападающему. Factotum позволил нам заключить за решетку привелегированное испольнение в единственный процесс ядро которого состоит всего из тысячи строк кода. Проверять такой процесс, как вручную, так и автоматически намного проще и снижается число ошибок которые отражаются на всех серверах.

rapidfx 29.04.09 в 19:41

Реализация этих идей есть в четвертой редакции Plan 9 от Bell Labs, свободно доступной по адресу http://plan9.bell-labs.com/plan9.

9. Признательности

rapidfx 29.04.09 в 19:41

William Josephson внес реализацию изменения пароля в secstore. Мы благодарим Phil MacKenzie и Martín Abadi за полезные коментарии на ранних этапах разработки. Chuck Blake, Peter Bosch, Frans Kaashoek, Sape Mullender, и Lakshman Y. N., predominantly Dutchmen, дали полезные замечания этому документу. Russ Cox'а поддержали товарищеские отношения со стороны Fannie и John Hertz Foundation.

Ссылки

rapidfx 29.04.09 в 19:41

[Bell93] S.M. Bellovin and M. Merritt, Augmented Encrypted Key Exchange,'' Proceedings of the 1st ACM Conference on Computer and Communications Security, 1993, pp. 244 - 250.

rapidfx 30.04.09 в 05:13

[Boyk00] Victor Boyko, Philip MacKenzie, and Sarvar Patel, Provably Secure Password-Authenticated Key Exchange using Diffie-Hellman,'' Eurocrypt 2000, 156­171.

rapidfx 30.04.09 в 05:13

[RFC2246] T . Dierks and C. Allen, The TLS Protocol, Version 1.0,'' RFC 2246.

rapidfx 30.04.09 в 05:14

[Ford00] Warwick Ford and Burton S. Kaliski, Jr., Server-Assisted Generation of a Strong Secret from a Password,'' IEEE Fifth International Workshop on Enterprise Security, National Institute of Standards and Technology (NIST), Gaithersburg MD, June 14 - 16, 2000.

rapidfx 30.04.09 в 05:14

[Jabl] David P. Jablon, Strong Password-Only Authenticated Key Exchange,'' http://integritysciences.com/speke97.html.

rapidfx 30.04.09 в 05:14

[Kami00] Michael Kaminsky. Flexible Key Management with SFS Agents,'' Master's Thesis, MIT, May 2000.

rapidfx 30.04.09 в 05:14

[Mack] Philip MacKenzie, private communication.

rapidfx 30.04.09 в 05:14

[Mazi99] David Mazières, Michael Kaminsky, M. Frans Kaashoek and Emmett Witchel, Separating key management from file system security,'' Symposium on Operating Systems Principles, 1999, pp. 124-139.

rapidfx 30.04.09 в 05:14

[Micr] Microsoft Passport, http://www.passport.com/.

rapidfx 30.04.09 в 05:14

[Perl99] Radia Perlman and Charlie Kaufman, Secure Password-Based Protocol for Downloading a Private Key,'' Proc. 1999 Network and Distributed System Security Symposium, Internet Society, January 1999.

rapidfx 30.04.09 в 05:14

[Pike95] Rob Pike, Dave Presotto, Sean Dorward, Bob Flandrena, Ken Thompson, Howard Trickey, and Phil Winterbottom, Plan 9 from Bell Labs,'' Computing Systems, 8, 3, Summer 1995, pp. 221-254.

rapidfx 30.04.09 в 05:15

[Pike93] Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, Phil Winterbottom, The Use of Name Spaces in Plan 9,'' Operating Systems Review, 27, 2, April 1993, pp. 72-76 (reprinted from Proceedings of the 5th ACM SIGOPS European Workshop, Mont Saint-Michel, 1992, Paper nº 34).

rapidfx 30.04.09 в 05:15

[Resc01] Eric Rescorla, SSL and TLS: Designing and Building Secure Systems,'' Addison-Wesley, 2001. ISBN 0-201-61598-3, p. 387.

rapidfx 30.04.09 в 05:15

[RFC2138] C. Rigney, A. Rubens, W. Simpson, S. Willens, Remote Authentication Dial In User Service (RADIUS),'' RFC2138, April 1997.

rapidfx 30.04.09 в 05:15

[RiLa] Ronald L. Rivest and Butler Lampson, SDSI--A Simple Distributed Security Infrastructure,'' http://theory.lcs.mit.edu/~rivest/sdsi10.ps.

rapidfx 30.04.09 в 05:15

[Schn] Bruce Schneier, Password Safe, http://www.counterpane.com/passsafe.html.

rapidfx 30.04.09 в 05:15

[Sama96] Vipin Samar, Unified Login with Pluggable Authentication Modules (PAM),'' Proceedings of the Third ACM Conference on Computer Communications and Security, March 1996, New Delhi, India.

rapidfx 30.04.09 в 05:15

[Stei88] Jennifer G. Steiner, Clifford Neumann, and Jeffrey I. Schiller, Kerberos: An Authentication Service for Open Network Systems,'' Proceedings of USENIX Winter Conference, Dallas, Texas, February 1988, pp. 191­202.

rapidfx 30.04.09 в 05:15

[Wu98] T. Wu, The Secure Remote Password Protocol,'' Proceedings of the 1998 Internet Society Network and Distributed System Security Symposium, San Diego, CA, March 1998, pp. 97-111.

rapidfx 30.04.09 в 05:15

[Ylon96] Ylonen, T., SSH--Secure Login Connections Over the Internet,'' 6th USENIX Security Symposium, pp. 37-42. San Jose, CA, July 1996.

rapidfx 30.04.09 в 05:16

Appendix: Summary of the PAK protocol

rapidfx 30.04.09 в 05:16

Let q>2^160 and p>2^1024 be primes such that p=rq+1 with r not a multiple of q. Take h�УУZp* such that g==h^r is not 1. These parameters may be chosen by the NIST algorithm for DSA, and are public, fixed values. The client C knows a secret ьЅ and computes H==(H1(C, ьЅ))r and H^-1, where H1 is a hash function yielding a random element of Zp*, and H^-1 may be computed by gcd. (All arithmetic is modulo p.) The client gives H^-1 to the server S ahead of time by a private channel. To start a new connection, the client generates a random value x, computes m==g^xH, then calls the server and sends C and m. The server checks m!=0 mod p, generates random y, computes ыЙ==g^y, ьА==(mH^-1)y, and sends S, ыЙ, k==sha1("server",C,S,m,ыЙ,ьА,H-1). Next the client computes ьА=ыЙx, verifies k, and sends k´==sha1("client",C,S,m,ыЙ,ьА,H^-1). The server then verifies k´ and both sides begin using session key K==sha1("session",C,S,m,ыЙ,ьА,H^-1). In the published version of PAK, the server name S is included in the initial hash H, but doing so is inconvenient in our application, as the server may be known by various equivalent names.

rapidfx 30.04.09 в 05:16