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

Почему я использую UML

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

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

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

UML как инструментарий

Одна большая ценность стандарта UML заключается в том, что он предоставляет инструменты, а не предписывает. Мой UML не является строгим. Иногда я использую стандартные элементы нестандартным образом. Но мои диаграммы соответствуют тому, что Мартин Фаулер назвал «наиболее полезной частью UML».

Стандарт UML — это инструмент, который поможет мне объяснить криптографию решения.

Что следует объяснить

Я объясню все следующее с помощью UML.

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

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

Пример требований к продукту

Чтобы проиллюстрировать, как использовать UML для объяснения криптографии, я собираюсь представить продукт с некоторыми требованиями безопасности. Затем я собираюсь предложить реализацию и объяснить криптографию реализации с помощью диаграмм UML.

Представьте, что продуктом является Digital Encabulator for Enterprise (DEE) версии 1. DEE может быть доступен конечным пользователям на мобильных устройствах, а также на портативных и настольных компьютерах. Требования безопасности заключаются в следующем.

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

• Код доступа устанавливается каждым конечным пользователем при установке приложения.
• Ключ пароля (PK) генерируется из кода доступа с помощью процесса PBKDF2 (функция получения ключа на основе пароля, версия 2) с этими параметрами.
  - Псевдослучайная функция кода аутентификации сообщения на основе хэша (HMAC).
  - Функция хеширования SHA256.
  - 20 000 итераций.
• Значение соли пароля (PS) включено во входные данные PBKDF2. PS будет генерироваться безопасным генератором случайных чисел (RNG).
• Значение PS постоянно хранится на устройстве. Ни значение PK, ни пароль не сохраняются.

• Защитите данные приложения с помощью промежуточного ключа шифрования данных (DEK). DEK будет длинным случайным значением, сгенерированным безопасным генератором случайных чисел. DEK будет иметь длину 256 бит, чтобы избежать угадывания грубой силой за практический промежуток времени.
• Храните DEK, зашифрованный с помощью PK, в постоянном хранилище устройства. Никогда не храните DEK в открытом виде в каком-либо постоянном хранилище. Для шифрования будет использоваться алгоритм AES Key Wrap.
• Когда пользователь меняет свой пароль, повторно зашифруйте DEK с новым значением PK. (Без DEK все данные приложения пришлось бы повторно шифровать при изменении пароля.)

• Предоставить услугу восстановления данных (DRS).
• DRS получит запрос на настройку (DRS-SU), когда конечный пользователь сгенерирует DEK на своем устройстве. DRS-SU будет включать идентификатор пользователя и требовать внеполосной аутентификации пользователя, например, путем перенаправления пользователя к поставщику удостоверений (IDP).
• Когда DRS получает DRS-SU, он создает пару ключей для асимметричного шифрования. Пара ключей содержит закрытый ключ (RIK), который создается и хранится в аппаратном модуле безопасности (HSM), и соответствующий открытый ключ (RUK). RIK будет иметь длину 2048 бит.
• DRS отвечает на DRS-SU, отправляя обратно RUK.
• Пользовательское приложение хранит DEK, зашифрованный с помощью RUK, в постоянном хранилище устройства. Шифрование будет использовать алгоритм RSA с дополнением PKCS1.
• Приложение конечного пользователя может отправить запрос на восстановление (DRS-RY) в DRS. DRS-RY будет включать идентификатор пользователя и требовать аутентификации пользователя, как и DRS-SU, и будет включать DEK, зашифрованный RUK.
• Когда DRS получает DRS-RY, DEK расшифровывается с помощью RIK в HSM. DRS отвечает на DRS-RY сообщением DEK.

• DRS может получить запрос аудита (DRS-AT). DRS-AT будет включать те же значения, что и DRS-RY, а также идентификатор пользователя аудита. Пользователю аудита потребуется авторизация.
• В остальном обработка DRS и ответ на DRS-AT такие же, как и для DRS-RY.

Эта диаграмма представляет основные криптографические функции в реализации в виде диаграммы классов UML.

Диаграмма выражает следующее.

Безопасный генератор случайных чисел — это класс. Его название будет сокращено до RNG.

• Экземпляры RNG имеют атрибут length со значением по умолчанию 256.
• Экземпляры ГСЧ имеют операцию getNext без параметров, которая возвращает биты длины.

• Экземпляры шифра имеют атрибут, алгоритм со значением по умолчанию AES-GCM (расширенный стандарт шифрования в режиме Галуа/счетчика).
• Экземпляры шифра имеют операцию шифрования, которая принимает два параметра, ключ и открытый текст, и возвращает шифрованный текст. Никаких подробностей о типах данных не дается.
• Экземпляры шифра имеют операцию расшифровки, которая принимает два параметра, ключ и зашифрованный текст, и возвращает открытый текст. Никаких подробностей о типах данных не дается.

Пример схемы развертывания

Эта диаграмма представляет хранение и защиту криптографических ресурсов в реализации в виде диаграммы развертывания UML.

Вставленное извинение: диаграмма отклоняется от стандарта UML следующим образом.

• Артефакты, например данные приложений, отображаются в виде прямоугольников без маркера документа.
  Маркер документа кажется излишним в стандарте. Из плоского прямоугольника уже ясно, что Application Data, например, не является средой выполнения.
• Объекты, например экземпляры ГСЧ, показаны на диаграмме развертывания.
  Используемый здесь стиль — прямоугольники с прямыми углами и подчеркнутым текстом — взят из стандарта диаграмм объектов UML.
  Чтобы нарисовать отдельную диаграмму объектов с теми же экземплярами, но без их развернутого контекста, читателю потребуется просмотреть дополнительную диаграмму.
• Метки на соединениях точно не показывают связь. Вместо этого они показывают имена параметров и, следовательно, отношения.
• Экземпляр асимметричного шифра отображается в среде оперативной памяти приложения. Это верно для шифрования, но неверно для расшифровки.
  Возможно, это можно было бы решить, расширив диаграмму, чтобы показать отдельные среды или документы для запроса на настройку DRS и запроса на восстановление DRS.

• Эти данные постоянно сохраняются приложением.
  - ПС.
  - DEK, зашифрованный PK.
  - Зашифрованные данные приложений.
  - DEK зашифрован RUK.
• Никакие другие данные не сохраняются приложением постоянно.
• RIK хранится в HSM внутри DRS.
• RUK создается DRS, но не сохраняется там.
• DEK хранится в зашифрованном виде с помощью двух разных ключей, RUK и PK. Для шифрования PK вместо используемого по умолчанию AES-GCM используется алгоритм AES-KW (Advanced Encryption Standard Key Wrap).
• PS — это случайное значение длины по умолчанию, 256. RIK и RUK основаны на случайном значении заданной длины, 2048.

• Данные приложения можно получить из постоянного хранилища, только если получен DEK.
• DEK можно получить из постоянного хранилища, если известен пароль. PS находится в постоянном хранилище, и PK можно получить, запустив KDF на секретном коде и PS.
• DEK также можно получить из постоянного хранилища, если доступен RIK. DEK, зашифрованный RUK, постоянно хранится и может быть расшифрован RIK. На диаграмме не указано, что DEK, зашифрованный с помощью RUK, должен быть отправлен в DRS для обработки дешифрования.

Пример диаграммы действий

Эта диаграмма представляет процесс установки секретного кода в виде диаграммы действий UML.

Используются следующие стандартные элементы.

• Действия, такие как вывод ключа, имеют закругленные углы.
• Узлы объектов с квадратными углами используются для представления криптографических ресурсов, таких как ключи и солт-значения.
• Пины, квадратики с текстовыми надписями, указывают параметры к действиям. Пины используются только в том случае, если имеется более одного параметра.
  - Входные параметры процесса encrypt() имеют контакты, потому что их два: ключ и открытый текст.
  - Выход процесса encrypt() имеет только один параметр, зашифрованный текст, поэтому у него нет булавки.
• Толстые полосы указывают на начало и конец независимой обработки. Например, RNG getNext() для генерации PS не зависит от пароля, являющегося параметром обработки KDF. Это может быть не совсем стандартно, но позволяет избежать двух потоков от ресурса, что определенно не является стандартным.

1. Обработка начинается после ввода пароля.
2. Безопасный генератор случайных чисел (RNG) запускается с длиной по умолчанию, как показано на диаграмме классов. Результатом является соль кода доступа (PS), которая хранится постоянно.
3. Функция получения ключа запускается с паролем в качестве секрета, значением PS в качестве соли, а также алгоритмом по умолчанию и количеством итераций, как показано на диаграмме классов. Результатом является ключ пароля (PK), который не сохраняется постоянно.
4. Другой ГСЧ запускается с длиной по умолчанию, как показано на диаграмме классов. На выходе получается ключ шифрования данных (DEK), который не хранится постоянно.
5. Процесс шифрования запускается с использованием PK в качестве ключа, DEK в качестве открытого текста и алгоритма AES-KW. Вывод сохраняется постоянно.

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

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

• Диаграммы классов показывают, какие криптографические стандарты и параметры используются.
• Диаграммы развертывания показывают, где хранятся ресурсы, если они хранятся, и какие ресурсы какими ключами защищены.
• Диаграммы действий показывают последовательность обработки. Узлы объектов показывают, какие ресурсы задействованы в обработке.

В качестве примера объяснения криптографии реального решения взгляните на официальный документ, опубликованный здесь.
developer.vmware.com/…/MobileApplicationManagement.pdf
(Схемы UML находятся в разделе Workspace ONE Шифрование данных в состоянии покоя под заголовком Диаграммы шифрования на основе пароля.)

Диаграммы в этой статье и в официальном документе были нарисованы с помощью инструмента charts.net , также известного как инструмент draw.io.

Справочную информацию о стандарте Unified Modeling Language (UML) см.https://uml.orgвеб-сайт и книгу Мартина Фаулера UML Distilled Third Edition.

Для справки по стандартам и терминам криптографии см. книгу «Серьезная криптография» Жана-Филиппа Омассона.