Протокол защиты периодического выполнения работ

Алиса и Боб обмениваются своими публичными PGP-ключами, аутентифицируют их, и синхронизируют часы. Алиса подписывает сообщение (о просьбе разбудить её) своим ключом, шифрует его ключом Боба и шлёт Бобу. Боб в нужное время шлёт аналогичное сообщение Алисе (подписанное и шифрованное) с командой звонка, в которое вставляет полученное от неё сообщение. Алиса анализирует: действительно ли сообщение подписано Бобом, действительно ли внутри есть сообщение от неё, подписанное её ключом, и действительно ли время в которое получена команда звкона совпадает с тем, которое она отослала Бобу в своём сообщении.

Боб по своему желанию не может будить в 7 утра Керол

Да, т.к. у Керол не найдёт внутри сообщения от себя к Бобу с просьбой разбудить в указанное время.

Боб может выполнить требуемые действия исключительно в указанное время (не может будить Алису в 5 утра, или по выходным)

Да, иначе метка времени на подписи и указанное время в сообщении от Алисы не совпадут и команда не сработает.

Мелори не может попросить будить Алису на час раньше

Да, т.к. ключи предварительно аутентифицированы и подделка сообщения сразу будет заметна.

Алиса не может утверждать, что она не просила будить ее в 7 утра

Да, т.к. у Боба имеется сообщение от Алисы с просьбой её разбудить подписанное её ключом, и он его может всем продемонстрировать.

Честно говоря, пока Шнайер не помогает, как бы вы решили эту задачу?

Мы в ваше время над домашними элементарными заданиями думали сами, а не лезли сразу же в интернет конец учебника за готовым ответом.

Моя ошибка в том, что я попытался перевести условия исходной задачи на классический язык, которым пока не владею.

Вариант с PGP не подходит, т.к. непосредственным объектом управления не всегда является Алиса (будильник в качестве примера).
В случае с будильником, Алисе нужно сначала проснуться, чтобы проверить подлинность команды.

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

Есть сервер приложений (Jboss), пользователь (Алиса) авторизуется в рамках некоторого web-приложения и видит на страничке список операций, на которые он может назначить задания. Назначив задания пользователь уходит и может вообще никогда больше не авторизоваться.

Jboss (Боб), получая из JAAS контекста все credentials текущего пользователя, создает в БД запись – Job.
Каждый раз, выполняя заданный Job, сервис Jboss-а авторизуется от имени создавшего этот Job пользователя.
Здесь Job – это некоторая операция, которая выполняется внутри сервера приложений: создание записи, передача сообщений, пинг ресурса наконец, условие одно – выполняться этот Job должен от имени кого-то.

Злоумышленник может получить доступ к:
– файловой системе сервера приложений
– базе данных Job-ов
– базе данных юзеров
– (совсем плохо) к консоли управления сервером приложений

Теоретически, можно было бы поступить так:
Боб, имея пароль Алисы, шифрует его каким нибудь из способов и записывает результат вместе с информацией о Job-e в базу. По наступлению нужного времени, из базы эта запись считывается, пароль расшифровывается, происходит авторизация и выполняется заданный Job.

Что это решает:
– доступ к БД не дает Мелори информации о пароле Алисы
– Т.к. все операции выполняются от имени Алисы, она не сможет отказаться от авторства

Недостатки здесь очевидны:
– где хранить пароль сервера приложений? да еще и таким образом, чтобы его компрометация не приводила к глобальному блокированию Job-ов?
– как обеспечить условие о недопустимости самодеятельности Jboss-а?

На ум приходит пока только ввод третьей стороны – сервера аутентификации – но пока это видение не очень ясное.

Вариант с PGP не подходит, т.к. непосредственным объектом управления не всегда является Алиса

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

Злоумышленник может получить доступ к:

Оперативной памяти? :)

Ваша изначальная постановка была ясная и криптографически чёткая, а потом вы навернули какую-то кашу, какой-то сервер приложений... То, что вам отвечено постом выше, будет работать при любом числе сторон в группе пользователей — зачем тогда вообще нужен сервис приложений? Не понятно кто и где выполняет работу (job). Должна ли она выполняться на сервере приложений или нет. Или идея в том что все пользователи сидят фактически за одним и тем же компьютером, который имеет доступ ко всему, включая ключи пользователей, да ещё и злоумышленник его взламывает? ну это решается частично только защитой и механизмами самой ОС. Криптографический протокол в любом случае требует, чтобы ряд операций производилась на "доверенном железе", т.е. на личном компьютере, который никому из атакующих не доступен.

Это что, курсовая? Или реальная задача? Лучше либо писать в абстрактном и ясном языке, как вы это сделали сначала, либо указывать конкретную технологическую задачу котору. нужно решить. Последние в 99% случаев решаеются довольно приемлемо безо всяких специальных криптопротоколов.

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

эта возможность исключается

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

Job – это некоторая операция, выполняющаяся сервером приложений. Сервер приложений сам инициирует выполнение операции, сама операция может быть локальной (внутри сервера приложений) так и затрагивать внешние ресурсы.

Производственная задача.

Еще немного подумав, я понял, что требования аутентификации от чужого имени и предотвращение несанкционированных действий – суть противоречащие.
Отсюда вывод: единственно возможным остается при создании Job-а генерация некоторого ключа, который позволил бы Бобу (серверу приложений)
– от имени данного пользователя выполнять задачи
– ограничить срок действия этого ключа, т.о. чтобы в не назначенный срок Job не м.б. выполнен
– данный ключ д.б. привязан к Алисе, т.е. ключ не м.б. подделан

Тогда вопросом остается – что это за ключ и как его сделать?

Спроектировать свой протокол аутентификации малореально, даже в теоретических курсах по доказуемой безопасности в основном только самые простые примеры и проектирование напоминает ходьбу по минному полю.

Есть масса работ по аутентификации, лучше максимально упростить задачу, ясно её сформулировать и подобрать готовый протокол.

В исходной задаче так и есть. Выше ответили, можно повторить примерно тоже. Непонятно только, что значит "разбудить". Алиса (сервер, клиент, железяка) может спать, но какая-то её часть (устройство, подпрограмма) должна иметь синхронизацию со временем. И в нужное время (или через промежутки) регулярно проверять почту или канал связи. У Боба будет подписанное Алисой (OpenPGP, OpenSSL, на чём угодно) расписание с одноразовыми аутентификационными ключами на основе MAC (MAC — Message Authentication Codes), электронными билетами (tickets, credentials) например на год вперёд (на весь календарь, с выбранными часами и днями недели). Этот список даёт Алисе неотрицаемость — она не может отказаться от него без утверждения, что её ключ скомпрометирован.

В неназначенное время Боб не сможет послать сообщение без нужного MAC из списка. Т.е. послать сможет, но Алиса отбросит такое сообщение или запрос сеанса связи. Мэллори вообще не сможет иметь аутентифицированную связь с Алисой ни в какое время.
Насчёт Кэрол — если она не давала аналогичных условий связи для Боба (с требованием ключей и расписаний), то он и не свяжется именно с ней. Если они хотят связываться как-то иначе по взаимному согласию, наплевав на протокол, то кто ж им помешает или заставит его выполнять?

Задача сводится к стандартному установлению аутентифицированного канала связи. Привязка ко времени здесь ничего существенно не меняет, кроме того, что Алисе всё равно нужно иметь достоверные часы и "самой" "просыпаться" и проверять сообщения. А аутентифицировать можно хоть биржевые сводки. Методы то одни.

в случае компрометации, Мелори может получить доступ к файловой системе Боба и выполнять SELECT-запросы к его таблицам пользователей и работ.

Есть такие работы, с темой "криптография на частично взломанных устройствах". Читать эти работы скучно. Неблагодарное это направление. Также как и защита от копирования.

Объяснения по поводу внутренней кухни с реализацией на сервере не очень понятны. Допустим там можно прикрутить что-то типа поиска по зашифрованной базе данных, причём "база не знает, что в ней ищут" и прочие заумные протоколы. Но это пустые мечты и работы для теоретиков.

Согласен, я слишком идеализирую ситуацию, проще обеспечить защиту технически/административно, чем велосипедировать с протоколами,
вот это я и пытался сделать :)

С будильником пример был просто для пояснения, попробую иначе.
Предположим, у данного форума есть такая опция:
Вы в личном кабинете задаете расписание – каждый день в 13.00 по питерскому отправлять от Вашего имени комментарий со случайным текстом в первые 10 постов.
Т.о. скрипт форума от Вашего имени периодически выполняет некое действие, при этом Вы не хотели бы, чтобы администратор по своему усмотрению менял время публикации комментариев или что-либо писал выдавая себя за Вас. Очевидно, Вы не хотите, чтобы пользователь kbykov мог создать от вашего имени подобный Job.

Что пришло в голову:
Таки есть необходимость разделить сервер приложений и сервер аутентификации.
Попробую объясниться языком как в самом начале.

1. Алиса, Боб и Трент имеют по паре закрытый/открытый ключ. Трент кроме того, имеет открытые ключи Алисы и Боба.
2. Алиса начинает работу с Трентом, авторизуясь хотя бы по RSA
3. Алиса, создавая Job (работая с Трентом!), создает соотв. MAC с меткой времени. Т.о. Трент хранит тройку значений: пользователь, джоб, подпись.
4. Боб начинает работу с Трентом, также авторизуясь по RSA.
5. Боб обращается к Тренту раз в 10 сек. за новым заданием, Трент уверен, что имеет дело с Бобом и потому авторизует его как Алису на время выполнения джоба.


Т.о. разделен орган управления доступом и непосредственный исполнитель, что это дает:
не может, т.к. авторизован под Алисой

только в указанное время, поставщиком указаний является Трент

Не может, либо ключа Мелори нет в базе, либо джоб м.б. создан только от имени Мелори.

не может, ибо MAC

Проблема в этой схеме насколько очевидна, настолько тривиальна:
повышенные требования к Тренту со всеми вытекающими.
Других очевидных изъянов приведенной схемы не вижу.

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

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

Протокол может надёжно гарантировать доставку нужного сигнала/команды в нужное время нужному лицу/программе/скрипту/устройству. Понятие "ответственности" — вообще за рамками криптографии, равно как и морали.

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

Сервер аутентификации нужен в тех случаях, когда общающиеся стороны не знают друг друга, либо не доверяют аутентификационным данным друг друга (unknown, я же прав?). Вы таких ограничений не выдвигали. Т.е. в вашей схеме Алиса и Боб всегда знают эти данные и могут удостовериться, что общаются именно с тем, с кем нужно (да, можно сказать, что это доп. ограничение).

Поэтому я постарался изложить суть оригинальной задачи, готов признать, возможно и это получилось не понятно.

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

Job – это некоторая операция, выполняющаяся сервером приложений. Сервер приложений сам инициирует выполнение операции, сама операция может быть локальной (внутри сервера приложений) так и затрагивать внешние ресурсы.

Откуда взялся сервер приложений, что это такое, и зачем он нужен? Напоминаю: у нас были общающиеся друг с другом стороны (Алиса, Боб и прочие) и противники, могущие вмешиваться в канал.

Еще немного подумав, я понял, что требования аутентификации от чужого имени

Зачем аутентифицироваться от чужого имени? Если вы говорите, что Боб — сервер приложений и выполняет какую-то работу у себя по запросу Алисы, то зачем нужна Алиса? Боб всегда может выполнить у себя всё что хочет? Вы хотите реализовать проверку согласия между Алисой и Бобом о выполнении каких-то действий на стороне Боба?

Предположим, у данного форума есть такая опция:
Вы в личном кабинете задаете расписание – каждый день в 13.00 по питерскому отправлять от Вашего имени комментарий со случайным текстом в первые 10 постов.
Т.о. скрипт форума от Вашего имени периодически выполняет некое действие, при этом Вы не хотели бы, чтобы администратор по своему усмотрению менял время публикации комментариев или что-либо писал выдавая себя за Вас. Очевидно, Вы не хотите, чтобы пользователь kbykov мог создать от вашего имени подобный Job.

Ну вот, наконец-то более-менее понятный пример, объяснённый понятным языком. Что ж, если быть чуть ближе к реальности, то такая задача неразрешима: администратор форума имеет полный доступ к его БД и потому всегда может редактировать посты как угодно, и писать их от кого угодно.

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

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

Сервер аутентификации нужен в тех случаях, когда общающиеся стороны не знают друг друга, либо не доверяют аутентификационным данным друг друга (unknown, я же прав?).

Тут похоже так и есть. Чётко сформулировано не было, но вероятно пользователей слишком много и они появляются и уходят как вздумается. Трент — доверенный каталог открытых ключей (используется для масштабирования аутентификационных и прочих данных на большое число незнакомых друг с другом пользователей и раздачи параметров заданий на выполнение).

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

Именно так и сформулировано. Трент — типа нотариуса, доверенной стороны. Можно (теоретически) его ещё связать цепочечными метками времени, чтобы он не мог пропускать задания или навесить на него криптоаудит, чтобы хотя бы задним числом проверять, что он не выдавал злонамеренных значений. Со всеми минусами и плюсами этой модели.

Понятие "ответственности" — вообще за рамками криптографии,

Это понятие удобно использовать при рассмотрении сложных систем. Например, в объектно-ориентированном программировании есть чисто технический термин "ответственность класса". Вы хотите сказать, что объекты криптографии не настолько сложны?

равно как и морали

Мораль есть фиксация ("snapshot") этики, которая на самом деле просто общественная оптимальность. А криптография – это экономика. ;)

Протокол может надёжно гарантировать доставку нужного сигнала/команды в нужное время нужному лицу/программе/скрипту/устройству. Понятие "ответственности" — вообще за рамками криптографии, равно как и морали.

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

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

1./comment42631
2. пример про форум

такую постановку поймет любой java-разработчик средней квалификации, есть конкретные вопросы – задавайте. вот как ниже:

Откуда взялся сервер приложений, что это такое, и зачем он нужен?

http://en.wikipedia.org/wiki/Application_server
это Боб в поставленной задаче.

Зачем аутентифицироваться от чужого имени?

1. Job создается конкретным пользователем, каждая операция выполняется от его имени.
2. Аутентификация в данном случае – ограничение реализации, при выполнении какой-либо операции Боб (сервер приложений) должен быть авторизован.

Боб всегда может выполнить у себя всё что хочет?

да, но, в идеале – только от своего имени. На выполнение от имени Алисы Бобу нужно разрешение.

Вы хотите реализовать проверку согласия между Алисой и Бобом о выполнении каких-то действий на стороне Боба?

я уже понял что это невозможно в поставленных условиях.

Можно придумать третий вариант: все безоговорочно доверяют администратору, но не доверяют другим пользователям форума.

в случае с Трентом именно так и есть.

мне кажется unknown постановку понял.

[демагогия]
Если прагматично понимать ответственность как "accountability", то протоколы с таким свойством есть. Раз, два.
[/демагогия]

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

Если протокол не формализован и не имеет доказательств стойкости (даже в самом очевидном и тривиальном случае) — это лишь эвристический протокол (попытку создания которого можно наблюдать в форуме).

Исправлено: ссылки внутри сайта делаются вот так — ((/comment12345))
безо всяких http(s) и пр.

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

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

Если все участники — пользователи одной о той же ОС на одной и той же машине, то наворачивать криптографию как защиту от компрометации системы бессмысленно, ибо ОС имеет доступ ко всем криптографическим ключам. Это тот случай, когда нужно действие — выполнение сервером приложений чего-то на своей же машине. Защита таких вещей строится на основе механизмов самой ОС.

Ещё можно об этом подумать как о системе, где ОС считается неуязвимой и доверенной, но в ней выполняются недоверенные программы, действие которых ОС должна чётко регламентировать. Я не слышал чтобы даже такая задача решалась средствами криптографии. Обычно это делается через систему так называемых политик, т.е. инструкций от ОС вида "что и когда может делать данный пользователь", плюс ведётся журнал на предмет выявления a posteriori совершённых нелегитимных действий.

Вы говорите про Алису, Боба и Трента. Криптографически в таком случае подразумевается, что каждый из них выполняет криптографические операции дома на койке под одеялом кранадашом на бумажке, или, в приближении естественных реалий, на собственном компьютере, который считается полностью доверяемым и неуязвимым. Из позже предоставленных деталей явствует, что Алиса и Боб работают за одной и той же машиной, в одной и той же ОС, что нарушает вышеуказанное допущение и обессмысливает криптографию между ними: система передаёт сообщения от одного пользователя к другому, имея ключи обоих из них, т.е. с точки зрения самой ОС криптографии между Алисой и Бобом нет вообще.

Вы хотите сказать, что объекты криптографии не настолько сложны?

Криптография — подобласть прикладной математики. Та часть программирования, которая имеет прозрачуню математическую трактовку, сводится либо к императивному, либо к функциональному программированию (в крайнем случае — к метапрограммированию), а ООП, имхо, — некоторая инженерная реализация одной из сугубо частных идей и вообще быдлокодерство из разряда worse is better