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

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

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

Итак, задача (данного исследовательского эксперимента, так его назовем) стояла следующая:

Разработать собственный алгоритм обратимого шифрования, притом что:

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

Поехали.

Для разработки было выбрано симметричное шифрование.

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

Описываемый здесь алгоритм более похож на поточный шифр, хотя не является им в чистом виде.
Задумывая реализацию алгоритма, в самых общих чертах было понимание, что секретный ключ должен быть лишь одним из элементов финального аккорда в симфонии шифрования, но не самим этим аккордом. То есть в идеале, говоря образно, каждое сообщение должно по хорошему как бы само шифровать себя, а ключ должен быть лишь некой стартовой точкой этого алгоритма, если хотите, неким инициализирующим вектором.
Основная идея прелесть получившегося алгоритма заключается в том, что для каждого акта шифрования не используется один и тот же секретный ключ, а генерируется функция обхода исходного ключа, так называемая сигнатура пути обхода (pathKeySignature в коде), причем функция зависит от нескольких аргументов. А именно от сложной комбинации sha-512 хешей соли приложения, исходного сообщения, уникального идентификатора uniqid, а также от хешкодов отправителя и получателя сообщения.
Что такое сигнатура обхода ключа на пальцах? Если упростить, это фактически алгоритм обхода ключа. Например, берем первый символ ключа, затем 14-ый, затем 22-ой, затем 37-ой, затем 49-ый и т.д. Каждый новый такой обход уникален (в силу уникальности генерируемого pathKeySignature).
Кроме того, в алгоритм внесены элементы двухфакторного шифрования (более подходящего термина не нашел, речь идет о коротких пин-паролях у отправителя и получателя, подробнее ниже по тексту). Далее, непосредственно "под капотом" используется обычный xor-метод.

"Двухфакторность" проявляется в том, что для генерации сигнатуры пути используются небольшие пароли (pass1 и pass2, по 4 символа), притом, что получателю неизвестен пароль отправителя, а отправителю неизвестен пароль получателя, но притом они обмениваются функциями-хешкодами от соли приложения и пароля второй стороны.

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

Предварительно магия начинается здесь.

private function attachKey($message, $salt)    {        return md5(hash('sha512', $message . uniqid() . $salt) . hash('sha512', $salt));    }    private function pathKeySignature($user_code_1, $user_code_2, $attach_key)    {        return hash('sha512', $user_code_1 . $attach_key . $user_code_2);    }

Собственно, наличие md5 хеш-функции может поначалу немного смутить, но этот элемент алгоритма отвечает лишь только за внесение хаотичности, лавинности изменений (как и sha512) в генерируемый attachKey. Функция uniqid отдает нам уникальный идентификатор, что по итогу позволяет шифровать одно и то же исходное сообщение каждый раз новым шифром, что в конечном счете гуд. Зачем так заморачиваться? Представьте, что вы разрабатываете свой месседжер с шифрованием. Шифрование одних и тех же сообщений одним и тем же конечным шифром если не прямая уязвимость, то явный шаг в ее сторону. Почему? Как правило, в данном контексте пользователи обмениваются весьма однотипным набором данных, из серии "привет!", "я понял", "ок", "скоро буду", "как дела?". Допустим, к примеру, у нас такой месседжер. Канал шифрования установлен, пользователь 1 отправил пользователю 2 шифрованное сообщение "0372985dee", пользователь 2 прочел сообщение и через 5 секунд ответил "0372985dee" обратно. Что зашифровано там? Ответ почти очевиден.
Это было лирическое отступление на тему уместности uniqid, возвращаемся к коду.

Магия продолжается здесь. Собственно, здесь в методе cipher происходит непосредственно обход ключа посредством сигнатуры $path_key_signature, а метод byteShifting дополнительно вносит хаотичность в генерируемый шифр посредством добавления различных сдвигов в определенных границах.

private function cipher($path_key_signature, $message, $generateKey)    {...        for ($i = 0; $i < count($message); $i++) {            if ($sign_key >= self::hash_length) $sign_key = 0;            $key_code_pos = hexdec($path_key_signature[$sign_key]);            $cur_key_pos = $cur_key_pos + $key_code_pos;            if ($cur_key_pos >= $key_length) {                $cur_key_pos = $cur_key_pos - $key_length;            }            $shifted_key_symbol = $generateKey[$cur_key_pos];            // byte shifting            $shifted_key_symbol = $this->byteShifting($i, $shifted_key_symbol);            $shifter = $this->mb_ord($message{$i}) ^ $this->mb_ord($shifted_key_symbol);            $cipher_message .= $this->mb_chr($shifter);            $sign_key++;        }        return $cipher_message;    }

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

public function codeMessage($message, $generateKey, $user1_pass, $receiver_hashcode)    {        $sender_hashcode = $this->sender_hashcode($user1_pass);        $attach_key = $this->attachKey($message, $this->salt);        $path_key_signature = $this->pathKeySignature($sender_hashcode, $receiver_hashcode, $attach_key);        $result_cipher = $this->cipher($path_key_signature, $message, $generateKey) . $attach_key;        $result_cipher = base64_encode($result_cipher);        return gzencode($result_cipher, 9);    }

Возможно, возникнет резонный вопрос. Почему бы не ограничиться в функции пути обхода просто одним attachKey, для чего добавлять туда хешкоды отправителя и получателя? Ответ находится тут же, "рядом" attachKey расположен фактически на виду в создаваемом шифре, и зная его, не составляет труда реконструировать последовательность прохождения ключа при шифре. Сам секретный ключ это, разумеется, напрямую восстановить не даст, но сведет на нет всю идею "рандомизации" ключа. Поэтому, нужен дополнительный фактор, которым являются хешкоды получателей. Они представляют собой своего рода второй секретный элемент алгоритма помимо ключа. Этакое своего рода двухфакторное шифрование.

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

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

• Относительно быстр по скорости шифрования/дешифрования (об этом ниже)
• Прост и понятен
• Открыт для изучения и улучшения, ибо опенсорс

Минусы:

• (скорее обстоятельство, чем недостаток) Требуется детальный анализ, чтобы понимать насколько он криптографически стоек.

В двух словах по поводу тестирования.
По скорости работы алгоритма относительно быстр (разумеется, все относительно и познается в сравнении, речь о скорости шифрования в рамках высокоуровнего яп вообще и в рамках php в частности). 2 мегабайта рандомного текста было зашифровано и расшифровано за 4 секунды, использовался при этом php 7.2. Система: Intel Core i7-8700 CPU @ 3.20GHz 12, параллельно еще работал браузер с кучей вкладок и виртуальная машина. Резюме скорость шифрования ~ 1 мб/сек на среднестатистическом железе на php7.0 и выше.

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

Обеспечение конфиденциальности данных и кода в образах контейнеров

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

Успех технологии контейнеризации в основном зависит от безопасности контейнеров на различных этапах их жизненного цикла. Одна из проблем безопасности наличие уязвимостей внутри отдельных контейнеров. Для их выявления пайплайны DevOps, используемые для создания контейнеров, дополняют сканерами, которые ищут в контейнерах пакеты с возможными уязвимостями и предупреждают их владельцев или технических специалистов в случае их обнаружения. Vulnerability Advisor в IBM Cloud является примером такой утилиты.

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

Еще одна потенциальная проблема безопасности это изоляция контейнера. Технологии безопасности среды исполнения Linux, такие как пространство имен, контрольные группы (cgroups), возможности Linux, а также профили SELinux, AppArmor и Seccomp, помогают ограничить процессы контейнеров и изолировать контейнеры друг от друга во время исполнения.

В этой статье рассматривается все еще актуальная проблема безопасности предприятий в отношении конфиденциальности данных и кода в образах контейнеров. Основная цель безопасности при работе с образами контейнеров позволить создавать и распространять зашифрованные образы контейнеров, чтобы сделать их доступными только определенному кругу получателей. В этом случае другие могут иметь доступ к этим образам, но они не смогут запускать их или видеть конфиденциальные данные внутри них. Шифрование контейнеров основано на существующей криптографии, такой как технологии шифрования Ривеста-Шамира-Адлемана (RSA), эллиптической кривой и Advanced Encryption Standard (AES), также известный как Rijndael симметричный алгоритм блочного шифрования.

Вводные

Чтобы получить максимальную пользу от прочтения этой статьи, вы должны быть знакомы с контейнерами Linux и образами контейнеров, а также иметь представление об основах безопасности.

Смежные работы по шифрованию и контейнерам

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

Зашифрованные файловые системы существуют во многих операционных системах на предприятиях и могут поддерживать монтирование зашифрованных разделов и каталогов. Зашифрованные файловые системы могут даже поддерживать загрузку с зашифрованного загрузочного диска. Linux поддерживает шифрование на уровне блочного устройства с помощью драйвера dm-encrypt; ecryptfs является одним из примеров зашифрованной файловой системы. Для Linux доступны другие решения для шифрования файлов с открытым исходным кодом. В ОС Windows шифрование поддерживает файловая система NTFS v3.0. Кроме того, многие производители создают диски с самошифрованием. Для образов виртуальных машин существует решение, подобное зашифрованным дискам. Эмулятор машины (ПК) QEMU с открытым исходным кодом и продукты виртуализации VMware поддерживают зашифрованные образы виртуальных машин.

Шифрование данных обычно направлено на защиту от кражи данных в то время, когда система отключена. Смежная технология это подписание образа контейнера ключом, который предоставляется клиентом и сервером Docker Notary. Сервер Docker Notary работает в непосредственной близости с реестром образов контейнера. Пользователи клиентского инструмента Docker имеют возможность подписать образ контейнера и загрузить подпись в свои учетные записи через Docker Notary. В ходе этого процесса подпись привязывается к образу контейнера через имя пути к образу и его версиям. Подпись создается с помощью хеш-функции, которая рассчитывается на основе описания всего содержимого образа. Это описание называется манифестом образа контейнера. Технология подписи образов контейнера решает проблему защиты образов контейнеров от несанкционированного доступа и помогает определить происхождение образа контейнера.

Структура

Экосистема Docker сформировалась для того, чтобы стандартизировать форматы образов контейнеров с помощью группы стандартов Open Container Initiative (OCI), которая теперь контролирует формат времени исполнения контейнера (runtime-spec) и формат образа контейнера (image-spec). Поскольку работа команды требовала расширения существующего формата образа контейнера, мы выделили расширение стандарта для поддержки зашифрованных образов. В следующих разделах описывается существующий формат образа контейнера и расширения.

На верхнем уровне контейнер может состоять из документа в Java Script Object Notation (JSON), который представляет собой список манифестов образов. Например, вы можете использовать этот список манифестов, когда для образа контейнера используются несколько архитектур или платформ. Список манифестов содержит ссылки на манифесты контейнеров, по одной для каждой комбинации архитектуры и операционной системы. Например, поддерживаемые архитектуры включают amd64, arm и ppc64le, а к поддерживаемым операционным системам относится Linux или Windows. Пример списка манифестов показан на скриншоте ниже:



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

Уровень ниже списка манифестов это манифест. Манифест также является документом JSON и содержит упорядоченный список ссылок на слои образов. Эти ссылки содержат mediaType, описывающий формат слоя. Формат может описывать, сжимается ли слой, и если да, то каким образом. Например, каждый уровень может быть сохранен в виде файла .tar, содержащего файлы, которые были добавлены на определенном этапе сборки при выполнении docker build в файле Docker. Для повышения эффективности хранения слои часто также упаковываются с использованием сжатых файлов .gzip. Пример документа манифеста показан на следующем скриншоте:



Как показано, манифесты и уровни ссылаются через дайджест, который обычно представляет собой хеш-функцию sha256 в документах JSON. Манифесты и слои обычно хранятся в виде файлов в файловой системе. Зачастую имена файлов представляют собой хеш-функции над содержимым, что упрощает их поиск и загрузку. Следствием этого метода хеш-функции является то, что небольшое изменение в документе, на который есть ссылка, вызывает изменения во всех документах, которые на него ссылаются, вплоть до списка манифестов.

В рамках проекта нашей команды мы создали шифрование образов на основе гибридной схемы шифрования с использованием открытого и симметричного ключей. Симметричные ключи используются для массового шифрования данных (применяются для многоуровневого шифрования), а открытые ключи используются для упаковки симметричных ключей. Мы использовали три различные технологии шифрования на основе открытых ключей: OpenPGP, JSON Web Encryption (JWE) и PKCS#7.

OpenPGP

OpenPGP это технология шифрования и подписи, которая обычно используется для шифрования и подписи сообщений электронной почты. Сообщества с открытым исходным кодом также часто используют его для подписания коммитов (тегов) исходного кода в репозиториях git. Это интернет-стандарт, определенный IETF в RFC480, и его можно рассматривать как открытую версию предыдущей проприетарной технологии PGP.

OpenPGP имеет собственный формат для ключей RSA. Ключи обычно хранятся в файле keyring и могут быть импортированы из простых файлов ключей OpenPGP. Наиболее удобный аспект keyring OpenPGP состоит в том, что открытые ключи могут быть связаны с адресами электронной почты их владельцев. Вы можете работать с несколькими получателями сообщения, просто выбрав список получателей по их адресам электронной почты, которые затем отображаются в открытых ключах для этих получателей. Кроме того, вокруг этой технологии была создана сеть доверия: вы можете найти открытые ключи многих пользователей, упорядоченные по их адресам электронной почты. Например, эти ключи часто используются для подписания тегов git.

Можно использовать формат зашифрованного сообщения OpenPGP для шифрования массовой рассылки сообщения для нескольких получателей. Заголовок сообщения OpenPGP содержит по одному блоку для каждого получателя. Каждый блок содержит 64-битный идентификатор ключа, который указывает алгоритму дешифрования, где необходимо пытаться дешифровать соответствующий закрытый ключ. После того как зашифрованный большой двоичный объект внутри блока расшифрован, он показывает симметричный ключ, который можно использовать для дешифрования массовой рассылки сообщения. Зашифрованный большой двоичный объект с открытым ключом каждого получателя показывает один и тот же симметричный ключ.

Мы использовали OpenPGP аналогичным образом, но в данном случае зашифрованное сообщение, которое он передает, не является слоем. Вместо этого оно содержит документ JSON, который, в свою очередь, содержит симметричный ключ, используемый для шифрования и дешифрования как слоя, так и вектора инициализации. Мы называем этот ключ ключом шифрования слоя (LEK), он представляет собой форму ключа шифрования данных. Преимущество этого метода в том, что нам нужен только один LEK. С помощью LEK мы шифруем слой для одного или нескольких получателей. У каждого получателя (образа контейнера) может быть свой тип ключа, и это не обязательно должен быть ключ OpenPGP. Например, это может быть простой ключ RSA. Пока у нас есть возможность использовать этот ключ RSA для шифрования LEK, мы сможем работать с несколькими получателями с разными типами ключей.

JSON Web Encryption (JWE)

JSON Web Encryption, также известное как JWE, является еще одним интернет-стандартом IETF и определено в RFC7516. Это более новый стандарт шифрования, чем OpenPGP, поэтому в нем используются более свежие низкоуровневые шифры, предназначенные для удовлетворения более строгих требований к шифрованию.

Если смотреть укрупненно, JWE работает по тому же принципу, что и OpenPGP, поскольку он также поддерживает список получателей и массовую рассылку сообщения, зашифрованного с помощью симметричного ключа, к которому имеет доступ каждый получатель сообщения. Получатели сообщения JWE могут иметь разные типы ключей, такие как ключи RSA, определенные типы ключей эллиптической кривой, предназначенные для шифрования, и симметричные ключи. Поскольку это более новый стандарт, все еще есть возможность расширения JWE для поддержки ключей в аппаратных устройствах, таких как TPM или модули аппаратной защиты (HSM), с использованием интерфейсов PKCS#11 или Key Management and Interoperability Protocol (KMIP). Использование JWE происходит аналогичным OpenPGP образом, если получатели имеют ключи RSA или эллиптические кривые. В будущем мы могли бы расширить его для поддержки симметричных ключей, таких как KMIP внутри HSM.

PKCS#7

PKCS#7, также известный как синтаксис криптографических сообщений (CMS), определен в стандарте IEFT RFC5652. Согласно Википедии о CMS, его можно использовать для цифровой подписи, дайджеста, аутентификации или шифрования любых форм цифровых данных.

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

Для поддержки ранее описанных технологий шифрования мы расширили документ манифеста, добавив следующую информацию:

• Сообщения OpenPGP, JWE и PKCS#7 хранятся в карте аннотаций, которая является частью манифеста.
• В каждом указанном слое содержится по одной карте. Карта аннотаций в основном представляет собой словарь со строками в качестве ключей и строками в качестве значений (пары ключ-значение).

Для поддержки шифрования образов мы определили следующие ключи:

• org.opencontainers.image.enc.keys.openpgp
• org.opencontainers.image.enc.keys.jwe
• org.opencontainers.image.enc.keys.pkcs7

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

Чтобы определить, что слой был зашифрован с помощью LEK, мы расширили существующие медиатипы суффиксом '+encrypted', как показано в следующих примерах:

• application/vnd.docker.image.rootfs.diff.tar+encrypted
• application/vnd.docker.image.rootfs.diff.tar.gzip+encrypted

Эти примеры показывают, что слой заархивирован в файле .tar и зашифрован или оба заархивированы в файле .tar и сжаты в файл .gzip и зашифрованы. На следующем скриншоте показан пример манифеста, который ссылается на зашифрованные слои. Он также показывает карту аннотаций, содержащую зашифрованное сообщение JWE.

Многослойное шифрование с использованием симметричных ключей

Для симметричного шифрования с помощью LEK наша команда выбрала шифр, который поддерживает аутентифицированное шифрование и основан на стандарте шифрования AES со 128- и 256-битными ключами.

Пример реализации: containerd

Мы реализовали наш вариант в новом проекте среды выполнения контейнеров под названием containerd. Его исходный код на golang можно посмотреть, перейдя по ссылке. Docker-демон использует containerd для запуска некоторых своих служб, а у Kubernetes есть плагин для прямого использования containerd. Поэтому мы надеемся, что наши расширения для поддержки зашифрованных образов контейнеров пригодятся обоим.

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

Поддержка алгоритмов аутентифицированного шифрования в Golang принимает байтовый массив в качестве входных данных и выполняет весь этап его шифрования (запечатывания) или дешифрования (открытия), не допуская передачи и добавления дополнительных массивов в поток. Поскольку этот криптографический API требовал загрузки всего уровня в память или изобретения некоторой схемы для изменения вектора инициализации (IV) для каждого блока, мы решили не использовать аутентифицированное шифрование golang с поддержкой связанных данных (AEAD). Вместо этого мы использовали крипто-библиотеку miscreant golang, которая поддерживает AEAD в потоках (блоках) и реализует собственную схему изменения IV в каждом блоке. В нашей реализации мы разбиваем уровень на блоки размером 1 МБ, которые и передаем один за другим для шифрования. Такой подход позволяет снизить объем памяти при использовании аутентифицированного шифра. На стороне дешифрования мы делаем обратное и обращаем внимание на ошибки, возвращаемые функцией Open (), чтобы убедиться, что блоки шифрования не были подделаны.

На уровне выше симметричного шифрования, асимметричные криптографические схемы шифруют LEK уровня и вектор инициализации (IV). Для добавления или удаления криптографических схем мы регистрируем каждую асимметричную криптографическую реализацию. Когда API асимметричного криптографического кода вызывается для шифрования уровня, мы вызываем один за другим зарегистрированные криптографические обработчики, передавая открытые ключи получателей. После того как все ключи получателей используются для шифрования, мы возвращаемся к карте аннотаций с идентификаторами асимметричных криптоалгоритмов в качестве ключей сопоставления и со значениями, содержащими сообщения в кодировке OpenPGP, JWE и PKCS#7. Каждое сообщение содержит упакованные LEK и IV. Карты аннотаций хранятся в документе манифеста, как показано на предыдущем скриншоте.

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

Мы использовали три типа асимметричных схем шифрования для разных типов ключей. Мы используем ключи OpenPGP для шифрования сообщений OpenPGP. PKCS#7, которую мы используем, требует сертификаты x.509 для ключей шифрования. JWE обрабатывает все остальные типы ключей, такие как простые ключи RSA, эллиптические кривые и симметричные ключи. Мы создали прототип расширения для JWE, который позволяет выполнять криптографические операции с использованием ключей, управляемых сервером KMIP.

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

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

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

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

Когда простой (незашифрованный) образ извлекается из реестра, он автоматически распаковывается и разархивируется, чтобы из него можно было сразу создавать контейнеры. Чтобы упростить это действие для зашифрованных образов, мы предлагаем передавать закрытый ключ команде, которая занимается распаковкой образов, чтобы они могли расшифровать слои до распаковки. Если образ зашифрован с помощью нескольких ключей, команде pull можно передать несколько. Такая передача также поддерживается. После успешного извлечения зашифрованного образа из реестра любой пользователь, имеющий доступ к containerd, может создать контейнер из образа. Чтобы подтвердить, что пользователь имеет права на использование образа контейнера, мы предлагаем ему предоставить закрытые ключи, используемые для расшифровки контейнера. Мы используем ключи для проверки авторизации пользователя, могут ли они использоваться для расшифровки LEK каждого зашифрованного уровня, и если это подтверждается, разрешаем запуск контейнера.

Пошаговое руководство шифрования с использованием containerd

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

В первую очередь, нужно клонировать репозиторий git containerd/imgcrypt, который является подпроектом и может шифровать/дешифровать образ контейнера. Затем необходимо собрать containerd и запустить его. Чтобы выполнить эти шаги, нужно знать, как настраивается среда разработки golang:

Для imgcrypt требуется использовать containerd версии не ниже 1.3.

Собираем и устанавливаем imgcrypt:

# make# sudo make install

Запустите containerd с файлом конфигурации, который можно увидеть на примере ниже. Чтобы избежать возникновения конфликта в containerd, используйте директорию /tmp для каталогов. Также соберите containerd версии 1.3 из исходника, но не устанавливайте его.

# cat config.tomldisable_plugins = ["cri"]root = "/tmp/var/lib/containerd"state = "/tmp/run/containerd"[grpc]  address = "/tmp/run/containerd/containerd.sock"  uid = 0  gid = 0[stream_processors]    [stream_processors."io.containerd.ocicrypt.decoder.v1.tar.gzip"]        accepts = ["application/vnd.oci.image.layer.v1.tar+gzip+encrypted"]        returns = "application/vnd.oci.image.layer.v1.tar+gzip"        path = "/usr/local/bin/ctd-decoder"    [stream_processors."io.containerd.ocicrypt.decoder.v1.tar"]        accepts = ["application/vnd.oci.image.layer.v1.tar+encrypted"]        returns = "application/vnd.oci.image.layer.v1.tar"        path = "/usr/local/bin/ctd-decoder"# sudo ~/src/github.com/containerd/containerd/bin/containerd -c config.toml

Создайте пару ключей RSA с помощью инструмента командной строки openssl и зашифруйте образ:

# openssl genrsa --out mykey.pemGenerating RSA private key, 2048 bit long modulus (2 primes)...............................................+++++............................+++++e is 65537 (0x010001)# openssl rsa -in mykey.pem -pubout -out mypubkey.pemwriting RSA key# sudo chmod 0666 /tmp/run/containerd/containerd.sock# CTR="/usr/local/bin/ctr-enc -a /tmp/run/containerd/containerd.sock"# $CTR images pull --all-platforms docker.io/library/bash:latest[...]# $CTR images layerinfo --platform linux/amd64 docker.io/library/bash:latest   #                                                                    DIGEST      PLATFORM      SIZE   ENCRYPTION   RECIPIENTS   0   sha256:9d48c3bd43c520dc2784e868a780e976b207cbf493eaff8c6596eb871cbd9609   linux/amd64   2789669                             1   sha256:7dd01fd971d4ec7058c5636a505327b24e5fc8bd7f62816a9d518472bd9b15c0   linux/amd64   3174665                             2   sha256:691cfbca522787898c8b37f063dd20e5524e7d103e1a3b298bd2e2b8da54faf5   linux/amd64       340                          # $CTR images encrypt --recipient jwe:mypubkey.pem --platform linux/amd64 docker.io/library/bash:latest bash.enc:latestEncrypting docker.io/library/bash:latest to bash.enc:latest$ $CTR images layerinfo --platform linux/amd64 bash.enc:latest   #                                                                    DIGEST      PLATFORM      SIZE   ENCRYPTION   RECIPIENTS   0   sha256:360be141b01f69b25427a9085b36ba8ad7d7a335449013fa6b32c1ecb894ab5b   linux/amd64   2789669          jwe        [jwe]   1   sha256:ac601e66cdd275ee0e10afead03a2722e153a60982122d2d369880ea54fe82f8   linux/amd64   3174665          jwe        [jwe]   2   sha256:41e47064fd00424e328915ad2f7f716bd86ea2d0d8315edaf33ecaa6a2464530   linux/amd64       340          jwe        [jwe]

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

# docker pull registry:latest# docker run -d -p 5000:5000 --restart=always --name registry registry

Отправьте зашифрованный образ в локальный реестр, извлеките его с помощью ctr-enc, а затем запустите образ:

# $CTR images tag bash.enc:latest localhost:5000/bash.enc:latest# $CTR images push localhost:5000/bash.enc:latest# $CTR images rm localhost:5000/bash.enc:latest bash.enc:latest# $CTR images pull localhost:5000/bash.enc:latest# sudo $CTR run --rm localhost:5000/bash.enc:latest test echo 'Hello World!'ctr: you are not authorized to use this image: missing private key needed for decryption# sudo $CTR run --rm --key mykey.pem localhost:5000/bash.enc:latest test echo 'Hello World!'Hello World!

Заключение

Шифрование образов контейнеров это хорошее дополнение к их безопасности, оно обеспечивает конфиденциальность данных и целостность образов контейнеров в месте хранения. Предложенная технология основана на общедоступных технологиях шифрования RSA, эллиптической кривой и AES. Она применяет ключи к схемам шифрования более высокого уровня, таким как OpenPGP, JWE и PKCS#7. Если вы умеете работать с OpenPGP, вы можете шифровать образы контейнеров для получателей OpenPGP, используя их адреса электронной почты, в то время как простые ключи RSA и эллиптические кривые используются для шифрования, например, JWE.

В начале 2019 года мы провели ребрендинг и поменяли название с RealtimeBoard на Miro. Следовательно, изменился домен сайта с realtimeboard.com на miro.com.

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

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

• Поддержать пользователей, которые выполняли авторизацию с помощью SSO провайдеров через старый домен.
• Передать токен авторизации пользователя со старого домена на новый.
• Передать LocalStorage с пользовательскими настройками приложения.

Передача данных и шифрование

Передавать токен было решено с помощью get-параметров, так как сайт не использовал хранилищ, в которых можно было бы сохранить токен и переиспользовать его. Передавать токен в открытую через get-параметр небезопасно, его необходимо защитить от перехвата. У нас было два способа шифрования: OpenSSL и Mcrypt. Mcrypt давно не обновлялся, медленнее шифрует данные по сравнению с OpenSSL, а лишняя нагрузка на сервер нам не нужна. Поэтому мы шифровали токен с помощью OpenSSL.

Однако полученный хэш всё равно можно было перехватить и использовать снова. Для того, чтобы токен нельзя было переиспользовать, мы добавили параметр дата шифрования, тем самым хэш был действителен в течении 10 секунд этого времени хватало с запасом для выполнения всех операций. Также мы добавили замену ключа шифрования раз в 12 часов, ключ хранился в Vault и был синхронизирован между сайтами.

Получившийся хэш передавался в виде get-параметра и был дополнительно обработан с помощью url_encode для безопасной передачи через URL, так как символы могли экранироваться или испортить структуру адреса.

Структура хэша:

url_encode(OpenSSL({  'token': 'токен',  'date': 'Дата шифрования',  'additional_values': ['param', 'param']}))

LocalStorage доступен только через JavaScript. Для решения этой задачи был выбран интерфейс postMessage и iframe, что позволяло безопасно отправлять кроссдоменные запросы. Данные в LocalStorage были сконвертированы в строки с помощью JSON.stringify() и переданы на домен miro.com, где они конвертировались обратно и записывались в LocalStorage домена miro.com.

Схема работы с описанием всех шагов

Схема в удобном для просмотра виде.

Пользователи могли попасть в сервис двумя путями: через старый домен realtimeboard.com (например, из закладок) или через новый miro.com (например, через рекламу).

Если пользователь заходил на старый домен:

1. После открытия любой страницы realtimeboard.com выполняется шифрование токена пользователя, даты создания и дополнительной служебной информации.
2. После шифрования происходит редирект на miro.com/migration/?data={hash} с передачей hash как Get параметр. Сам токен и служебная информация удаляются на старом домене, т.к они больше были не нужны.
3. На новом домене miro.com выполняется расшифровка хэша, проверка на то, что он не просрочен, и установка токена пользователя, если он был передан.
4. Проставляется флаг migrationToken, чтобы не выполнять миграцию снова.
5. Для миграции LocalStorage мы проверяли наличие куки migrationLocalstorage. Если куки не существовало, выполнялся рендеринг страницы с JS-скриптом, который открывал в iFrame страницу relatimeboard.com/localstorage/ и принимал сообщения от неё с помощью postmessage После окончания миграции пользователя редиректило на страницу, которую он пытался открыть первый раз.

Если пользователь заходил сразу на новый домен miro.com, выполнялась проверка на прохождение пользователем миграции токена и LocalStorage. Если пользователь уже выполнил миграцию, то он оставался на домене miro.com. Если не выполнил происходил редирект на realtimeboard.com для получения токена (для этого мы хранили в куках два флага: migrationToken и migrationLocalstorage).

Эта схема так же хорошо работала для пользователей с SSO, которые выполнили авторизацию на старом домене realtimeboard.com. Был добавлен список маршрутов, которые работали без миграции токена на новый домен. В них входил маршрут для SSO, который выполнялся как обычно и выполнял редирект на /app/ или /login/ в зависимости от состояния своей работы, после чего снова подключался механизм миграции токена.

Вывод

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

Привет, Хабр! У нас отличная новость для тех, кто предпочитает обезопасить свои данные, которые хранятся не только на внутренних накопителях ПК и ноутбуков, но и на съемных носителях. Дело в том, что 20 июля наши американские коллеги из Kingston объявили о выпуске трех USB-накопителей с поддержкой стандарта USB 3.0, емкостью 128 Гбайт и функцией шифрования. Если быть точнее, речь идет о моделях Kingston DataTraveler Locker+ G3, Kingston DataTraveler Vault Privacy 3.0 и Kingston DataTraveler 4000 G2. Далее по тексту мы детально поговорим о каждом из накопителей и расскажем, что они умеют, помимо обеспечения безопасности.

Kingston DataTraveler Locker+ G3: беспрецедентная защита

Флешка Kingston DataTraveler Locker+ G3 (доступная с емкостями 8, 16, 32, 64 а теперь и 128 Гбайт) обеспечивает защиту персональных данных с помощью аппаратного шифрования, а также позволяет установить пароль для доступа к информации, что обеспечивает двойной уровень защиты. Накопитель выполнен в прочном металлическом корпусе и оснащен удобной петличкой, чтобы цеплять флешку на связку ключей (aka брелок). Таким образом, накопитель всегда будет с вами (если вы не из тех, кто постоянно теряет ключи от дома и офиса, конечно).

DataTraveler Locker+ G3 прошлого поколения зарекомендовали себя на рынке как одни из самых надежных устройств хранения данных. К тому же эти накопители не требуют сложных настроек: одна из опций позволяет настроить резервное копирование данных с флешки в облачное хранилище Google, OneDrive, Amazon Cloud или Dropbox. А это уже фактически тройная защита.

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



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

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

Потерять накопитель тоже не страшно. Система безопасности не позволит злоумышленникам или обычным мамкиным хакерам взломать вашу флешку методом подбора паролей. После 10 неудачных попыток ввода DataTraveler Locker+ G3 автоматически отформатируется и уничтожит все данные (однако в облачном хранилище они останутся).

Kingston DataTraveler Vault Privacy 3.0: для бизнеса

Флешка DataTraveler Vault Privacy 3.0 (DTVP 3.0) обеспечивает защиту классом повыше и ориентирована на бизнес-сегмент: в частности, накопитель поддерживает аппаратное 256-битное AES-XTS-шифрование и оснащен прочным алюминиевым корпусом, который защищает флешку от физических воздействий, и герметичным колпачком для предотвращения попадания влаги и пыль на USB-коннектор. Интересная особенность заключается еще и в поддержке ОС Linux, а не только распространенный систем на базе Windows и Mac.

Как и в случае с предыдущей флешкой (Kingston DTLPG3) при использовании DataTraveler Vault Privacy 3.0 вам нужно просто установить пароль и накопитель будет содержать все записанные данные в полной безопасности от постороннего вторжения. Функция защиты от взлома здесь аналогичная: 10 попыток на ввод пароля, после чего информация на флешке уничтожается. Хакнуть флешку методом брутфорса у злоумышленников не получится от слова совсем.



Что еще предлагает нам корпоративная флешка? Во-первых, на борту у нее есть утилита Drive Security, которую можно использовать для сканирования внутренней емкости на наличие проблем с безопасностью (таких как вредоносные программы или вирусы). Во-вторых, предусмотрен доступ в режиме только чтения данных, что позволяет избежать потенциального риска заражения ПК (то есть, при наличии вируса на флешке он не сможет внедрить вредоносный скрипты на другие ПК, к которым подключается накопитель).

Ранее в продаже были доступны накопители DataTraveler Vault Privacy 3.0 с емкостями 4, 8, 16, 32 и 64 Гбайт, а с обновлением линейки добавилась модель с емкостью 128 Гбайт. Что ж, вкупе с AES-шифрованием Kingston DataTraveler Vault позволит не переживать за возможные утечки ценной информации, зная, что ваши данные защищены серьезным шифрованием

Kingston DataTraveler 4000 G2: защита на уровне правительства

В накопителе Kingston DataTraveler 4000 G2 акцент также сделан на защиту данных, но здесь он еще более серьезный, чем у Kingston DTVP 3.0. Вместе с емкостью в 128 Гбайт конечный пользователь получает несколько уровней расширенной защиты, так что предложение выгодное. И если безопасность является приоритетом рассматривать DataTraveler 4000 G2 в качестве покупки имеет смысл. Устройство выполнено в прочном корпусе из нержавеющей стали, обладает герметичной заглушкой и как и вышеназванные продукты предлагает 256-битное аппаратное AES-XTS-шифрование для надежной защиты информации на флеш-памяти.



Кроме того, флешка сертифицирована по стандарту FIPS 140-2 Level 3 Validation (стандарт безопасности для накопителей, использующихся в правительстве США). Также накопитель обладает защитой от несанкционированного доступа (при неверном вводе пароля свыше 10 раз данные удаляются), режимом доступа только для чтения (во избежании заражения компьютеров) и возможностью централизованного управления накопителем на корпоративном уровне (удаленная настройка паролей и изменение политики устройства и т.п.). Стоит отметить, что утилита для удаленного управления и настройки накопителей не входит в пакет ПО и приобретается отдельно. Впрочем, для любой компании это вполне допустимые затраты.

Результаты тестов уже скоро

И самое главное новые флешки уже едут к нашим специалистам, которые проведут тотальное тестирование образцов и подробнее расскажут о том, на какие скорости передачи данных могут рассчитывать пользователи, и как реализованы алгоритмы шифрования. К этому времени Kingston DataTraveler Locker+ G3, Kingston DataTraveler Vault Privacy 3.0 и Kingston DataTraveler 4000 G2 как раз станут доступными для продаж по всему миру.

Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.

В данной статье объясняется механизм, используемый игрой Castlevania III: Draculas Curse для сохранения и восстановления игрового состояния при помощи паролей. Информация статьи относится к североамериканским и PAL-версиям, выпущенным для NES, а не к японской версии, Akumaj Densetsu, выпущенной для Famicom.

Система имён и паролей

В Castlevania III применена комбинированная система имени и пароля. В начале игры игроку нужно ввести имя:


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

После game over игроку даётся на выбор два варианта: мгновенно продолжить игру с последней точки сохранения или закодировать игровое состояние в пароль, позволяющий продолжить играть в будущем.


При выборе PASSWORD отображается следующий экран:


В данном случае введено имя EXAMPLE, оно показано в поле в верхней части экрана. Непосредственно под именем находится горизонтальная таблица, содержащая используемые в паролях значки: пустота, хлыст, чётки и сердце. Под таблицей расположен пароль матрица 44, в которой каждый элемент является значком. Обратите внимание, что пароли обычно бывают разреженными матрицами.

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

Для восстановления игрового состояния игрок сначала выбирает в главном меню пункт PASSWORD:


Как показано ниже, игроку предлагается ввести связанное с паролем имя.


Далее игрок переходит на экран ввода пароля:


На экране есть два голубых курсора, один из которых выбирает значок из горизонтальной таблицы, а другой помещает значок в матрицу пароля. Здесь показан введённый пароль.


В случае правильного ввода игра продолжается с точки сохранения. Однако даже при минимальной ошибке демонстрируется следующее сообщение:


Обычно это получается из-за неправильно расположенного значка или забытого имени. Пароль работает только для введённого в начале игры имени.

Особые имена

5 особых имён влияют на геймплей:


Несмотря на то, что показал Angry Video Game Nerd в своём видео Castlevania (Part 2), имя HELP ME содержит пробел.

Особые имена OKUDA, URATA и FUJIMOTO начинают обычный режим с напарником, однако при этом они принуждают использовать этого напарника всю оставшуюся игру. Получение или переключение напарников аналогичным образом отключены и в сложном режиме. В случае AKAMA это означает, что сложный режим придётся полностью проходить в одиночестве.

На некоторых веб-сайтах утверждается, что при использовании имени GAMETEAM в сочетании с особым паролем позволяет начать в сложном режиме. И если игрок успешно пройдёт игру, то будут показаны настоящие титры с именами разработчиков, создававших игру. Это правда, но больше в этом сочетании имени и пароля нет ничего необычного. Альтернативные титры являются наградой за прохождение сложного режима, вне зависимости от имени. Более того, в альтернативных титрах раскрывается происхождение особых имён:

Игровое состояние

Пароли содержат в себе точку сохранения, напарника и режим. Это единственные свойства игрового состояния, остающиеся, когда игрок продолжает после game over. Всё остальное сбрасывается.

Точки сохранения

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


Существует 18 точек сохранения, индексированных с $00 по $11. Названия локаций и боссов никогда не встречаются в игре; в различных источниках есть разные описания. Однако значения блоков и подблоков отображаются в интерфейсе. Все блоки начинаются с подблока 1 или A, за исключением Forest of Darkness, в который можно войти с точек сохранения $03 или $04:


Единственные прочие точки сохранения посередине блока это $02 и $0A из-за наличия мини-боссов:


Точки сохранения $0B и $0C имеют общие значения блока. Но это два совершенно разных уровня:

Напарник

Существует 4 значения для напарника, индексированные от 0 до 3:


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


Эта проверка не проводится для особых имён, за исключением HELP ME. Остальные особые имена с самого начала привязывают игру к конкретному напарнику, или, в случае AKAMA, к отсутствию напарника.

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

То же самое относится и к AKAMA, однако при нём всегда используется сложный режим (Hard Mode), вне зависимости от закодированного в пароле режима.

Режим

Есть два значения для режима, индексированные 0 и 1:


После прохождения игры в Normal Mode она перезапускается в Hard Mode, который значительно сложнее с самого начала. В нём больше врагов, они движутся быстрее и наносят больше урона. На скриншоте внизу слева показаны первые экраны Normal Mode. Справа показаны их аналоги из Hard Mode с дополнительными врагами.


Напарник, связанный с игроком в конце Normal Mode, переносится в Hard Mode. Однако возможность смены напарников в Hard Mode отключена; игрок постоянно остаётся с одним напарником или без напарника, если Normal Mode был пройден в одиночку.

После прохождения игры в Hard Mode она перезапускается, но не в каком-то более сложном режиме. В игре всего два режима, и Hard Mode бесконечно зациклен.

Хэш имени

Вместо полного 8-символьного имени пароль содержит всего лишь 3-битный хэш. Хэш вычисляется прибавлением 4 к сумме значений всех символов и делением с остатком на 8 для получения значения в интервале 07:



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

; hashName(); out: A = name hash (0--7)03:B6CD  LDA #$0003:B6CF  STA $0000    ; sum = 0;03:B6D1  TAX03:B6D2  LDA $07F8,X  ; for (X = 0; X < 8; ++X) {03:B6D5  CLC03:B6D6  ADC $B6E6,X03:B6D9  CLC03:B6DA  ADC $000003:B6DC  STA $0000    ;     sum += name[X] + NAME_HASH_SEEDS[X];03:B6DE  INX03:B6DF  CPX #$0803:B6E1  BNE $B6D2    ; }03:B6E3  AND #$07     ; A = sum % 8;03:B6E5  RTS          ; return;; NAME_HASH_SEEDS; Due to the modulo operation, this table is pointless; the values can be tallied ahead of time. However, the; intention may have been to apply this table only to the nonblank characters. But that check is not there.03:B6E6  .byte $07, $03, $01, $06, $02, $04, $05, $00

Как и указано в комментариях, эта таблица не имеет смысла. Вероятно, разработчики намеревались прибавлять константы только к непустым символам. Однако по какой-то причине эту проверку оставили.

Значения символов это индексы тайлов в таблице паттернов. Как показано ниже, AZ, за которыми следуют восклицательный и вопросительный знаки, соответствуют $50-$6B. Точка это $4B. Пробел это $00.


Особые имена хэшируются точно так же, как и любые другие. То же самое относится и к пустому имени, которое записывается как 8 пробелов.

Полезная нагрузка

Пароль содержит в себе 1-байтную полезную нагрузку и 1-байтный хэш полезной нагрузки.

Содержимое

Байт полезной нагрузки содержит режим (бит 0), напарника (биты 12), индекс маски переключения (бит 3), младший бит точки сохранения (бит 4) и хэш имени (биты 57):

76543210--------NNNSTPPM режим напарник  индекс маски переключения бит 0 точки сохранения хэш имени

Индекс маски переключения задаётся случайным образом при генерации пароля. Он влияет на способ вычисления хэша полезной нагрузки. Поскольку есть 2 возможных значения, то существует 2 действительных пароля для каждого имени, напарника и режима. Например, если игрок начинает новую игру с пустым именем и многократно получает game over в первом блоке, то игра рано или поздно покажет пару эквивалентных паролей:

Хэш

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

Для вычисления хэша полезной нагрузки выполняются следующие шаги:

1. Старший и младший полубайты байта полезной нагрузки считаются 4-битными целыми числами и складываются:
   
   

   nibbleSum = 0x0F & ((payload >> 4) + payload);
   

2. Если индекс маски переключения равен 0, то чётные биты байта полезной нагрузки переключаются (0 1 и 1 0 для битов 0, 2, 4 и 6). Это реализовано выполнением XOR с $55:
   
   

   toggledPayload = payload ^ 0x55;
   

   
   В противном случае нечётные биты переключаются с помощью XOR с $AA:
   
   

   toggledPayload = payload ^ 0xAA;
   

3. Старший и младший полубайты переключенного байта полезной нагрузки считаются 4-битными целыми числами и складываются:
   
   

   toggledNibbleSum = 0x0F & ((toggledPayload >> 4) + toggledPayload);
   

4. Две 4-битные суммы комбинируются в байт, при этом первая сумма, становится старшим полубайтом, а вторая младшим:
   
   

   sums = (nibbleSum << 4) | toggledNibbleSum;
   

5. Точка сохранения и байт сумм складываются. Так получается 8-битный хэш полезной нагрузки:
   
   

   payloadHash = 0xFF & (savePoint + sums);
   

Описанные выше шаги задают однонаправленную хэш-функцию. Из этого хэша никак не получится восстановить полезную нагрузку.

Представление строк

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


В представлении строки i-тый значок является конкатенацией i-того бита байта нагрузки и i-того бита байта хэша. Другими словами, из полезной нагрузки берётся старшие биты, а из хэша младшие биты. Для создания значка они объединяются для каждого индекса бита.

Кодирование

Кодирование это процесс преобразования имени и игрового состояния в пароль. В нём используются следующие шаги.

1. Имя хэшируется.
2. Индексу маски переключения назначается случайное значение.
3. Хэш имени, бит 0 точки сохранения, индекс маски переключения, напарник и режим побитово конкатенируются, образуя нагрузку.
4. Полезная нагрузка хэшируется.
5. Полезная нагрузка и её хэш преобразуются в строку из 8 значков.
6. Точка сохранения делится на 2 (сдвигом вправо на 1). При этом создаётся значение в интервале 08, которое выражается как значок в матрице паролей в соответствии с показанной ниже таблицей.
   
   
   
7. Первый значок может встречаться в одном из трёх мест:
   
   
   
   
   Каждое из этих мест является первым элементом одной из следующих последовательностей скрэмблирования.
   
   
   
   
   Элементы 18 последовательности скрэмблирования заполняются 8 значками в строке, созданной из полезной нагрузки и её хэша. Так как строка содержит пустые символы и только 9 из 16 элементов матрицы становятся значками, пароли обычно являются разрeженными матрицами.

Декодирование

Декодирование это процесс преобразования имени и пароля в игровое состояние. Оно состоит из следующих шагов.

1. Введённое имя хэшируется.
2. В действительном пароле непустой значок встречается только в одном из мест, помеченных ниже.
   
   
   
   
   Если непустой значок содержит несколько таких мест или все три пустые, то пароль отклоняется.
3. При помощи показанной ниже таблицы непустой значок преобразуется в значение из интервала 08.
   
   
   
   
   Точка сохранения является удвоенной величиной от этого значения.
4. Непустой значок является первым элементом одной из следующих последовательностей скрэмблирования.
   
   
   
   
   В действительном пароле 7 элементов матрицы паролей, не включённых в последовательность скрэмблирования, должны быть пустыми. Если любой из них непуст, то пароль отклоняется.
5. С помощью элементов 18 последовательности скрэмблирования создаётся строка из 8 значков.
6. Полезная нагрузка и хэш полезной нагрузки извлекаются, соответственно, из старших и младших битов значков строки.
7. Если бит 4 полезной нагрузки задан, то выполняется инкремент точки сохранения.
8. Из полезной нагрузки извлекаются режим, напарник и хэш имени.
9. Введённое имя сравнивается с особыми именами, кроме HELP ME. Если это не одно из оставшихся особых имён и режим обычный, то проверяется сочетание точки сохранения и напарника. Напарник может использоваться только по пути точек сохранения, начинающихся с момента встречи напарника в игре. Если сочетание неверно, то пароль отклоняется.
10. Хэш введённого имени сравнивается с хэшем имени, извлечённым из полезной нагрузки. Если они не совпадают, пароль отклоняется.
11. Полезная нагрузка хэшируется. Результат сравнивается с хэшем полезной нагрузки, извлечённым из пароля. Если они не совпадают, пароль отклоняется.

Все пароли

Полная таблица всех 3294 действительных сочетаний имени и пароля приведена здесь.

Каждый столбец соответствует точке сохранения. Каждая строка соответствует уникальному сочетанию имени, напарника, индекса маски переключения и режима. Поскольку имя хэшируется в 3-битное значение, существует всего 8 классов имён. Как показано в таблице ниже, кратчайшими именами, охватывающими все классы, являются пустое имя и имена, состоящие из одной буквы с B по H. Эти имена показаны в левой части каждой строки.


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

Белые и красные имена в таблице по ссылке соответствуют Normal Mode и Hard Mode. Имя AKAMA встречается написанное только красным цветом, потому что оно подразумевает Hard Mode вне зависимости от записанного в пароле режима. Однако пароли для AKAMA, содержащие Normal Mode, всё равно действительны и для полноты приведены в таблице.

Спрайтами слева от каждой строки обозначены напарники.

Индекс маски переключения обозначен направлением, в котором смотрит Тревор: вправо это 0, влево 1. Индекс маски переключения не влияет на геймплей, но удваивает количество действительных паролей.

Пропуски в таблице соответствуют недопустимым сочетаниям точки сохранения и напарника. В Normal Mode без особого имени напарника можно использовать только по пути из точек сохранения, начинающегося, когда напарник впервые встречается в игре.

Все особые имена, кроме HELP ME, привязывают игрока к конкретному напарнику. Однако напарник, записанный в пароле, имеет приоритет перед тем, который связан с особым именем. Поэтому особые имена встречаются в таблице в сочетании со всеми напарниками.

Код

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

Программа на Java, сгенерировавшая полную таблицу паролей, выложена здесь.