Мой опыт написания сервера ключей/значений «без знаний».
Я говорил вам, что будет вторая часть — и вот она.
Ты хоть помнишь, как мы оказываемся в part deux? Позвольте мне быстро напомнить вам: в моем беспорядочном перетасовке страниц MDN я наткнулся на этот особенно ядовитый (TOXIC) самородок относительно WebCrypto API:
Человек слишком глупый, чтобы обращать на это внимание, я решил посвятить некоторое время тому, чтобы стать новичком в криптографии. Как бы то ни было, это все древняя история: бессвязное вступление см. в Часть первая. В нем использовалась какая-то метафора динозавра (примечание: теперь я могу произнести слово пахицефалозавр, не глядя на него).
История происхождения
Это мало кто знает, а этот классный сайт thegoldenmule.com? Я владею этим. Это я — это то место, куда я клал вещи, когда у меня было время что-то делать. Мой личный аккаунт на GitHub называется, соответственно, thegoldenmule. Меня много раз спрашивали, почему золотой мул, и в этот момент, устав от всего чертового внимания (которого я получаю так много), я просто говорю: назван в честь книги» и остановимся на этом.
Это только полуправда, так как рассматриваемая книга на самом деле называется Золотой Осел: латинская книга, написанная во втором веке нашей эры. Ненавистники будут ненавидеть, но я бы сказал, что это также лучший латинский роман второго века. В юности у меня не было средств, чтобы поставить слово задница в моем личном доменном имени, хотя сейчас у меня может быть наглость (если вы помните из предыдущего поста, я планирую сделать татуировку , что довольно резко).
Эта книга не о загорелых ягодицах.
Сюжет вращается вокруг любопытства главного героя (curiositas) и ненасытного желания видеть и практиковать магию. При попытке произнести заклинание, чтобы превратиться в птицу, он случайно превращается в осла. Это ведет к долгому путешествию, буквальному и метафорическому, наполненному рассказами.
теперь понимаешь? Я главный герой, технологии — это волшебство, и, согласно неформальному опросу моих коллег, на данном этапе моей карьеры я думаю, что я, возможно, пошел полным ходом. Поэтому, когда я вижу технологию, которая настолько сложна, настолько загадочна, настолько волшебна, что мне даже не разрешено ее использовать, — ну, это действительно заводит меня… камбуз в снаряжении.
Теперь — что на самом деле сделать с этим запрещенным API?
Представляем НК
Это не требует подробного повествования, объясняющего мои рассуждения (у нас уже около 350 слов в этом посте, и — черт возьми, эта полоса прокрутки точна?!) — достаточно сказать, что я очарован внутренней криптографической работой Биткойна, моя личная электронная почта хранится в зашифрованном виде на сервере в Швейцарии, и у меня довольно серьезная ненависть к Evernote как к худшему программному продукту, за который я регулярно плачу, так и к лучшему в своем роде на рынке.
Что вы получите, если соедините эти диковинки вместе?
Представляем Nk: экспериментальный сервер без знаний и Nk Notes: онлайн-демонстрация создания заметок с броским названием.
Я неплохой программист, поэтому я думаю о композиции простых частей: простой сервер без знаний, простой API и простой клиент.
Мы просто поцарапаем зуд сервера в этом посте.
Зачем нужны серверы без знаний?
Хранение данных на сервере является необходимостью, характерной для большинства современных приложений. Мы часто создаем небольшой микросервис для хранения пользовательских данных (просто храним несколько двоичных объектов json!) или, возможно, используем Parse или Firebase. Общий принцип при создании этих служб заключается в том, что сервер никогда не должен доверять клиентам. Я бы сказал, что это единственный реалистичный подход. Всех клиентов все время взламывают, друг мой, так что держи эти грязные немытые руки клиентов подальше от моих приятных вещей.
Мы склонны думать, что этот подход работает без проблем — ну, если не считать записок Сноудена проблемой. Или, э-э, Кембридж Аналитика. Или, подождите, давайте я быстро проверю https://haveibeenpwned.com/:
Ну ладно, всего лишь три взломанных аккаунта на каждый интернет, использующий мужчину, женщину и ребенка на Земле. Я также читаю, что Gmail может и читает мою электронную почту? Подождите, Dropbox регулярно читает мои файлы, а также позволяет правительству просматривать их, когда захочет? Напоминаем, что с 2017 года случайные сотрудники Evernote могут читать ваши личные заметки без какого-либо четкого процесса или причины, почему.
Возможно, нам следует добавить второй, ммм, более злобный принцип: клиент никогда не должен доверять (извините за выражение) ленивым-недоученным-программистам или технологическим компаниям-приверженцам. to-shareholder-profit-margins со своими данными.
Таким образом, клиенты не должны доверять серверам, а серверы не должны доверять клиентам. Это делает мой простой «микросервис пользовательских данных» немного сложнее.
Подождите, что такое не-знание?
Нет знаний не означает Нулевых знаний. Я знаю, это утверждение звучит математически подозрительно, если не сказать больше. Доказательства с нулевым разглашением — это очень конкретно определенные конструкции, в то время как отсутствие знаний не имеет определенного академического значения. Я позаимствовал термин у компании SpiderOak, которая предлагает Dropbox без знаний (среди прочего). Я следил за ними довольно долго и был очень заинтересован в их безопасности (но, к сожалению, очень не впечатлен пользовательским интерфейсом).
Из их блога:
Отсутствие знаний означает, что мы предоставляем вам полную конфиденциальность ваших данных — то, что мы делали с самого начала. Из-за того, что мы создаем наши продукты со сквозным шифрованием, мы ничего не знаем об именах или содержимом ваших файлов. Даже если бы мы захотели, мы не можем видеть, что вы храните или чем делитесь, а также ваши разговоры. Ваши файлы шифруются до того, как они покинут ваше устройство и будут переданы. Только у вас есть ключ на вашем устройстве для их расшифровки. Ваши данные полностью защищены от наших системных администраторов, ваших собственных системных администраторов, хакеров, слепой безосновательной повестки в суд или любой угрозы.
Мне также нравится это небольшое дополнение: «… это означает, что мы никогда не сможем сбросить ваш пароль. И хорошее эмпирическое правило заключается в том, что любая компания, которая может сбросить ваш пароль, потенциально может получить доступ к вашим данным или прочитать их, поскольку у них есть ключ для их разблокировки».
Блестящий.
Короче говоря, защищенный микросервис пользовательских данных должен обладать двумя свойствами:
- Он не должен иметь возможности читать данные, которые он хранит.
- Он должен знать как можно меньше о том, кто хранит данные.
Как nk подходит к этой проблеме
К счастью, вокруг бегают люди поумнее меня.
Оказывается, мы можем сделать это простым способом, не изобретая буквально ничего нового. Когда вы поймаете себя на том, что ломаете голову над какой-то сложной задачей программирования, найдите утешение в том, что она, вероятно, была решена в какой-то момент в 1960-х годах кем-то с интересной фамилией именем.
Для создания учетной записи Nk не требуется ничего, кроме правильно заполненного открытого ключа RSA.
Затем Nk генерирует уникальный идентификатор пользователя, сохраняет его рядом с открытым ключом и возвращает идентификатор пользователя.
К счастью для клиентов, открытые ключи предназначены для того, чтобы быть — ну, открытыми. Таким образом, когда nk в конечном итоге будет скомпрометирован, открытый ключ будет единственным фрагментом незашифрованной PII, которая будет у злоумышленника. Никаких электронных писем, неправильно засоленных паролей, никаких пользовательских данных в открытом виде. Nk даже не хранит метки времени.
Как только клиент создал идентификатор, он может немедленно сохранить данные. Они делают это, указывая ключ (т. е. имя), полезную нагрузку и подпись для полезной нагрузки. Клиент может, конечно, сделать все это открытым текстом, но это было бы глупо, потому что, как я полагаю, мы уже говорили: мы не доверяем серверам. Позвольте мне проверить — немного прочитав страницу — да, мы уже рассмотрели этот момент.
Не надо. Доверять. Серверы.
Библиотека nk-js создает и использует симметричный ключ шифрования для шифрования полезной нагрузки перед подписанием и отправкой. В приведенном ниже примере клиент выбрал открытый текстовый ключ foo. Это, конечно, также может быть зашифровано — на усмотрение клиента.
Здесь нет необходимости в заголовке авторизации, поскольку сервер может просто найти открытый ключ пользователя и использовать его для проверки двух вещей:
- Что подпись соответствует полезной нагрузке и, следовательно, не была изменена третьей стороной.
- Что подпись была создана владельцем закрытого ключа.
Обновление данных работает почти так же, однако получение данных немного отличается. Как мы можем убедиться, что владелец закрытого ключа запрашивает данные, если клиент не «вошел в систему»?
Для этого nk использует простую систему доказательств.
Во-первых, клиенты запрашивают новое доказательство с сервера.
Затем сервер генерирует и возвращает случайную полезную нагрузку.
Отсюда клиент просто подписывает эту полезную нагрузку своим закрытым ключом и использует как доказательство, так и подпись в заголовке запроса GET для извлечения своих данных.
Это обеспечивает доказательство того, что клиент владеет закрытым ключом. Аналогичная конечная точка существует для получения списка ключей. Библиотека nk-js прозрачно запрашивает и предоставляет вам доказательства за кулисами.
Ответный удар!
Теперь наблюдательные среди вас, возможно, заметили здесь поверхность атаки: клиент доверяет доказательству, которое сервер дает ему для подписи. — Н-н-н-но ты сказал не доверять серверам! Я слышу, как ты болтаешь. Перестань так дрожать, большой ребенок.
Это, по-видимому, очень опасно, так как сервер может выбрать полезную нагрузку, которая будет раскрывать информацию о закрытом ключе при подписании. Будущая версия nk (по крайней мере, в моей голове) будет разделять подписанную полезную нагрузку между клиентом и сервером: то есть клиент выбирает часть полезной нагрузки доказательства, а сервер выбирает часть полезной нагрузки. Таким образом, ни клиент, ни сервер не имеют полного контроля над полезной нагрузкой, которую клиент должен подписать. Кроме того, РСА-ОАЭП видимо просто устойчив к этой атаке, так что, наверное, в какой-то момент мне стоит переключиться.
В заключение, Nk: не используйте его
Да, это, вероятно, хорошая идея — по крайней мере, было бы, если бы такие вещи уже существовали. Это действительно единственный сервер без знаний с открытым исходным кодом? Это искренний вопрос, уважаемые читатели. Не может быть, не так ли? Но даггумит, я не могу найти ничего, что удовлетворяло бы ту же потребность.
В следующем посте я хотел бы рассказать о клиенте nk. Как оказалось, писать было очень весело, и да, хотите верьте, хотите нет, но создание приложения для создания заметок, которое работает лучше, чем Evernote, на самом деле осталось всего на выходных.
Посмотрим. Я выписываю много чеков «будущей почты», которые мои пальцы не могут обналичить.
