модуль ara::crypto — Cryptography

Функциональный кластер Cryptography предоставляет стандартизированные сервисы безопасности для симметричного и асимметричного шифрования, проверки подписи, а также безопасного управления ключами и сертификатами (PlatformDesign с. 71). Доступ к криптографическим операциям и постоянным слотам ключей строго изолирован через платформозависимые провайдеры и декларативно зафиксированные в манифесте спецификаторы экземпляров (SWS Cryptography с. 39). Обеспечение соблюдения ограничений на использование предотвращает компрометацию конфиденциального ключевого материала ([SWS_CRYPT_50092]).

больше ›

Функциональный кластер Cryptography (ara::crypto) предоставляет комплексную архитектуру безопасности для AUTOSAR Adaptive Platform (PlatformDesign с. 71). Для защиты от скомпрометированных пользовательских приложений хранение ключей и криптографическое выполнение обычно инкапсулированы в изолированном демоне платформы или аппаратном модуле безопасности (HSM) (AUTOSAR AP EXP SWArchitecture с. 97, SWS Cryptography с. 87). Общая функциональность подразделяется на специализированные CryptoProvider для вычислительных примитивов, область Key Storage для постоянных слотов ключей (KeySlots), а также общемашинный X509Provider для управления сертификатами PKI (SWS Cryptography с. 39).

Контекстная диаграмма: архитектурные связи и взаимосвязи компонентов функционального кластера Cryptography между приложением, демоном и провайдерами. Источники: SWS Cryptography с. 39, PlatformDesign с. 71, AUTOSAR AP EXP SWArchitecture с. 97.

Приложения создают криптографические контексты, такие как симметричные шифры ([SWS_CRYPT_20742]), аутентифицированные шифры ([SWS_CRYPT_20745]), хеш-функции ([SWS_CRYPT_20747]) или экземпляры Signer и Verifier ([SWS_CRYPT_20756], [SWS_CRYPT_20757]), через свой провайдер (AUTOSAR AP EXP SWArchitecture с. 99). Обработка следует детерминированному жизненному циклу: после привязки ключа (SetKey) трансформация инициируется через Start(), передается потоком через Update() и завершается с помощью Finish() (AUTOSAR AP TR SystemTests с. 206, EXP SWArchitecture с. 104). Неизменяемые AllowedUsageFlags эффективно предотвращают несанкционированное использование ключей ([SWS_CRYPT_50092], AUTOSAR AP TR SystemTests с. 177).

Диаграмма состояний: жизненный цикл контекстов криптографической трансформации от выделения памяти до сброса. Источники: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Сертификаты и CSR управляются через X509Provider ([SWS_CRYPT_40099], [SWS_CRYPT_40640]), в то время как контексты валидации проверяют цепочки сертификатов с учетом списков отзыва CRL ([SWS_CRYPT_50183]) и ответов OCSP ([SWS_CRYPT_50124]) (AUTOSAR AP TR SystemTests с. 194). Назначение KeySlots и сертификатов приложениям выполняется на основе модели в манифесте через InstanceSpecifier (AUTOSAR AP TPS ManifestSpecification с. 245, AUTOSAR AP TPS ManifestSpecification с. 649). Все интерфейсы работают с возвращаемыми значениями ara::core::Result без исключений и сигнализируют об ошибках через CryptoErrorDomain ([SWS_CRYPT_19902], SWS Cryptography с. 208).

больше ›

Архитектура, домены безопасности и изоляция демона

Функциональный кластер Cryptography (ara::crypto) формирует центральную основу безопасности AUTOSAR Adaptive Platform и предоставляет базовые криптографические механизмы, управление ключами, а также сервисы сертификатов (PlatformDesign с. 71). Согласно модели доверия платформы, функциональные кластеры платформы относятся к доверенному фундаменту, тогда как Adaptive Applications выполняются в непривилегированном пользовательском пространстве (SWS Cryptography с. 37). Чтобы эффективно защитить ключевой материал и криптографические операции даже при потенциальной компрометации приложения, архитектура обычно построена на основе демона; само выполнение и хранение ключей остаются в изолированном процессе платформы или в доверенной среде выполнения (AUTOSAR AP EXP SWArchitecture с. 97, SWS Cryptography с. 87).

Архитектура разделяет криптографическую функциональность на три основных домена: CryptoProvider для вычислительных примитивов и преобразований ключей, область Key Storage (ara::crypto::keys) для постоянного хранения объектов, а также X509Provider (ara::crypto::x509) для управления сертификатами (SWS Cryptography с. 39, SWS Cryptography с. 87). На одном электронном блоке управления (ECU) могут параллельно существовать несколько специализированных экземпляров CryptoProvider, например, для подключения различных аппаратных модулей безопасности (HSM, TPM) или программных драйверов (SWS Cryptography с. 39). Однако между различными провайдерами намеренно отсутствует интероперабельность: криптографический объект или ключ принадлежит строго одному провайдеру и не может обрабатываться другим провайдером (SWS Cryptography с. 39). Эта строгая инкапсуляция, вероятно, обусловлена главным образом тем, что аппаратные домены безопасности физически принудительно устанавливают границы своих ключей, и дескрипторы ключей недействительны между доменами. Вопрос Q-63efe107cf111983 (открытый)

Контекстная диаграмма: архитектурные связи и взаимосвязи компонентов функционального кластера Cryptography между приложением, демоном и провайдерами. Источники: SWS Cryptography с. 39, PlatformDesign с. 71, AUTOSAR AP EXP SWArchitecture с. 97.

Точки входа и инициализация криптографических провайдеров

Вход в модуль осуществляется через глобальные функции входа, которые служат фабриками для центральных интерфейсов абстракции (SWArchitecture с. 71). Приложения создают или загружают экземпляр CryptoProvider через функцию [SWS_CRYPT_20099] с указанием смоделированного ara::core::InstanceSpecifier. Для управления сертификатами во всей системе существует ровно один глобальный провайдер сертификатов, который загружается через [SWS_CRYPT_40099] (SWS Cryptography с. 39). Дополнительно доступны глобальные вспомогательные службы, включая прямое создание случайных данных через [SWS_CRYPT_30098], а также запрос аппаратного счетчика безопасности через [SWS_CRYPT_20098] (SWArchitecture с. 71).

Постоянные ключевые ресурсы не инстанцируются напрямую, а загружаются через логические слоты ключей (KeySlots). Для этого среда выполнения предоставляет функции [SWS_CRYPT_50004] для доступа только на чтение и [SWS_CRYPT_50005] для слотов ключей с возможностью записи, которые валидируют переданный идентификатор экземпляра на соответствие конфигурации полномочий (SWS Cryptography с. 87, AUTOSAR AP TPS ManifestSpecification с. 649). Через полученный экземпляр KeySlot можно запросить связанный экземпляр провайдера с помощью [SWS_CRYPT_30403], благодаря чему сохраняется строгая привязка между местом хранения и средой выполнения (SWS Cryptography с. 39).

Как только экземпляр CryptoProvider становится доступен, он функционирует как центральная фабрика для инстанцирования конкретных криптографических рабочих контекстов (AUTOSAR AP EXP SWArchitecture с. 99). К создаваемым контекстам относятся, в частности, контексты для генераторов случайных чисел ([SWS_CRYPT_20741]), симметричных блочных и потоковых шифров ([SWS_CRYPT_20742]), аутентифицированного шифрования ([SWS_CRYPT_20745]), кодов аутентификации сообщений ([SWS_CRYPT_20746]), криптографических хеш-функций ([SWS_CRYPT_20747]), асимметричного шифрования или расшифрования ([SWS_CRYPT_20750], [SWS_CRYPT_20751]), а также контексты подписи и верификации ([SWS_CRYPT_20756], [SWS_CRYPT_20757]) (EXP SWArchitecture с. 99).

Криптографические контексты трансформации и обработка данных

Обработка криптографических данных в ara::crypto следует строго основанному на состояниях жизненному циклу, который обеспечивает развязку конфигурации алгоритма, привязки ключа и потоковой обработки (AUTOSAR AP TR SystemTests с. 211). После выделения контекста через провайдер он изначально находится в неинициализированном состоянии. Только после передачи совместимого ключа через типоспецифичные перегрузки SetKey() — например, для симметричных ключей ([SWS_CRYPT_23911]), закрытых ключей ([SWS_CRYPT_23515]) или непосредственно из KeySlot ([SWS_CRYPT_50043]) — контекст переходит в готовое состояние (AUTOSAR AP TR SystemTests с. 206).

Для потоковой обработки трансформация инициируется с помощью Start(), опционально с передачей вектора инициализации или контекста ([SWS_CRYPT_22110], [SWS_CRYPT_23625], [SWS_CRYPT_50020]). Затем блоки данных могут поэтапно подаваться через Update() ([SWS_CRYPT_21113], [SWS_CRYPT_22113], [SWS_CRYPT_50139]). При аутентифицированном шифровании (AEAD) интерфейс строго разделяет ассоциированные данные, обрабатываемые через [SWS_CRYPT_20313], и конфиденциальные полезные данные, передаваемые через [SWS_CRYPT_50074] (EXP SWArchitecture с. 104). Завершение трансформации выполняется через Finish() или FinishEncrypt() ([SWS_CRYPT_21115], [SWS_CRYPT_23618], [SWS_CRYPT_50075]), после чего теги аутентификации или контрольные суммы могут быть считаны через GetDigest() ([SWS_CRYPT_21116], [SWS_CRYPT_22116]).

Помимо потокового режима, такие классы контекстов, как симметричные шифры и аутентифицированные шифры, поддерживают компактные однократные вызовы через [SWS_CRYPT_50047] или [SWS_CRYPT_50078], благодаря чему короткие полезные нагрузки могут эффективно шифроваться или расшифровываться без многоэтапного вызова протокола (SWS Cryptography с. 58). Если текущую операцию требуется прервать, вызов Cancel() ([SWS_CRYPT_50023], [SWS_CRYPT_50046]) или Reset() ([SWS_CRYPT_50212]) детерминированно возвращает контекст в очищенное исходное состояние (EXP SWArchitecture с. 100).

Диаграмма состояний: жизненный цикл контекстов криптографической трансформации от выделения памяти до сброса. Источники: [SWS_CRYPT_20742], [SWS_CRYPT_23911], [SWS_CRYPT_23625], [SWS_CRYPT_50046], [SWS_CRYPT_50212].

Управление ключами, инкапсуляция и обеспечение соблюдения полномочий

Криптографические ключи типизируются в объектной модели как CryptoObject или RestrictedUseObject (AUTOSAR AP EXP SWArchitecture с. 111, EXP SWArchitecture с. 111). Стандарт платформы различает симметричные ключи (SymmetricKey), закрытые асимметричные ключи (PrivateKey) и открытые ключи (PublicKey) (SWS Cryptography с. 291). Ключевой материал может генерироваться напрямую через CryptoProvider ([SWS_CRYPT_20721], [SWS_CRYPT_20722]) или выводиться из существующего ключевого материала путем параметризации KeyDerivationFunctionCtx ([SWS_CRYPT_20748]) базовым ключом и его выполнения через [SWS_CRYPT_21515] (EXP SWArchitecture с. 108).

Для обеспечения соблюдения принципа наименьших привилегий каждый объект ключа содержит неизменяемые ограничения на использование (AllowedUsageFlags), которые могут быть запрошены через [SWS_CRYPT_50092] (AUTOSAR AP TR SystemTests с. 177). Криптографический стек при каждой попытке привязки (SetKey) проверяет, авторизована ли операция целевого контекста (например, шифрование, подписание, вывод или экспорт) флагами ключа, и строго отклоняет недопустимые варианты использования (AUTOSAR AP TR SystemTests с. 177, SWArchitecture с. 95). Стандартное назначение для алгоритма можно определить через [SWS_CRYPT_20955].

Для безопасного обмена ключами модуль реализует несколько стандартизированных процедур: при асимметричном согласовании ключей (Диффи — Хеллман / ECDH) через [SWS_CRYPT_20758] создается KeyAgreementPrivateCtx, к которому привязывается закрытый ключ ([SWS_CRYPT_21313]); затем метод [SWS_CRYPT_21312] с привлечением открытого ключа противоположной стороны вычисляет общий симметричный целевой ключ (AUTOSAR AP TR SystemTests с. 179). В механизме инкапсуляции ключей (KEM) KeyEncapsulatorPublicCtx ([SWS_CRYPT_20752]) инкапсулирует симметричный ключ с помощью [SWS_CRYPT_21813], в то время как противоположная сторона выполняет декапсуляцию через KeyDecapsulatorPrivateCtx ([SWS_CRYPT_20753]) посредством [SWS_CRYPT_21412] (AUTOSAR AP TR SystemTests с. 173, AUTOSAR TR AdaptivePlatformSystemTests с. 188). Для защищенной транспортировки ключей доступны упаковка ключей (Key Wrapping) ([SWS_CRYPT_24014], [SWS_CRYPT_24016]) и защищенный экспорт ([SWS_CRYPT_20728]) (AUTOSAR AP TR SystemTests с. 174, AUTOSAR AP TR SystemTests с. 182).

Диаграмма последовательности: асимметричное согласование ключей через Диффи — Хеллмана и формирование симметричных рабочих ключей. Источники: [SWS_CRYPT_20758], [SWS_CRYPT_21313], [SWS_CRYPT_21312], AUTOSAR AP TR SystemTests с. 179.

Асимметричные подписи обрабатываются через раздельные контексты: подписание выполняется через SignerPrivateCtx ([SWS_CRYPT_20756]) и метод [SWS_CRYPT_23512], тогда как верификация осуществляется через VerifierPublicCtx ([SWS_CRYPT_20757]) и метод [SWS_CRYPT_24112] (AUTOSAR AP TR SystemTests с. 164, SWArchitecture с. 84). Если KeySlot обновляется в фоновом режиме привилегированными службами управления (например, при смене ключей OTA), использующие библиотеки могут быть уведомлены через наблюдатель обновлений (Update-Observer) посредством [SWS_CRYPT_30404] для синхронной подгрузки своего ключевого материала (AUTOSAR AP SWS Cryptography с. 36).

Диаграмма последовательности: процесс формирования и верификации подписи с использованием раздельных закрытых и открытых контекстов. Источники: [SWS_CRYPT_20756], [SWS_CRYPT_23515], [SWS_CRYPT_23512], [SWS_CRYPT_20757], [SWS_CRYPT_24115], [SWS_CRYPT_24112], AUTOSAR AP TR SystemTests с. 164.

Управление сертификатами X.509, валидация и группы

Подсистема ara::crypto::x509 предоставляет стандартизированные функции для инфраструктур открытых ключей (PKI) (EXP SWArchitecture с. 116). Центральный X509Provider ([SWS_CRYPT_40099]) поддерживает как энергонезависимое сессионное хранилище, так и персистентные хранилища (SWS Cryptography с. 39). Сертификаты и цепочки разбираются из байтовых буферов с помощью [SWS_CRYPT_40614] или [SWS_CRYPT_40616]. Для запроса новых идентификационных сертификатов приложения могут генерировать криптографически подписанные запросы на подпись сертификата (CSR) через [SWS_CRYPT_40640], при этом контекст подписывающей стороны (Signer) и различающееся имя (DN) передаются через [SWS_CRYPT_50186] (AUTOSAR AP TR SystemTests с. 189).

Для проверки соответствия и срока действия приложение инстанцирует CertificateValidationCtx через [SWS_CRYPT_50125]. В этот контекст добавляются якоря доверия (Trust Anchors) через [SWS_CRYPT_50117], параметры валидации определяются через [SWS_CRYPT_50120], а эталонные метки времени сохраняются через [SWS_CRYPT_50121]. Иерархическая проверка цепочки по отношению к цепочке доверия выполняется с помощью [SWS_CRYPT_50122] или [SWS_CRYPT_50123] (AUTOSAR AP TR SystemTests с. 194). Для учета отзывов сертификатов могут импортироваться списки отзыва сертификатов (CRL) ([SWS_CRYPT_50183]) либо в статус валидации могут включаться онлайн-запросы статуса сертификатов (OCSP согласно RFC 6960) через [SWS_CRYPT_40626], [SWS_CRYPT_50185] и [SWS_CRYPT_50124] (AUTOSAR AP TR SystemTests с. 194).

Чтобы отвязать потребителей сертификатов от отдельных экземпляров сертификатов при смене ключей, манифест поддерживает концепцию CryptoCertificateGroup (AUTOSAR AP TPS ManifestSpecification с. 657). Потребляющие приложения загружают всю группу логически связанных сертификатов через [SWS_CRYPT_50126], тогда как привилегированные службы администрирования могут динамически заменять или очищать сертификаты через [SWS_CRYPT_50127] и [SWS_CRYPT_50128] (AUTOSAR AP TPS ManifestSpecification с. 657).

Диаграмма последовательности: валидация сертификатов X.509 с цепочкой сертификатов, импортом CRL и онлайн-проверкой статуса OCSP. Источники: [SWS_CRYPT_40099], [SWS_CRYPT_50125], [SWS_CRYPT_50122], [SWS_CRYPT_50183], [SWS_CRYPT_50124], AUTOSAR AP TR SystemTests с. 194.

Моделирование манифеста, портовые интерфейсы и развертывание

Интеграция криптографических ресурсов в общую архитектуру транспортного средства осуществляется декларативно через метамодель AUTOSAR в манифесте ARXML (AUTOSAR AP TPS ManifestSpecification с. 244). Программные компоненты моделируют свои требования безопасности на уровне проектирования через порты (RPortPrototype), типизируемые специализациями CryptoInterface: CryptoKeySlotInterface для ключевых слотов, CryptoCertificateInterface для ресурсов сертификатов и CryptoProviderInterface для доступа к провайдерам выполнения (TPS ManifestSpecification с. 167, AUTOSAR AP TPS ManifestSpecification с. 245). Атрибуты интерфейсов неизменно определяют, предоставляются ли права на чтение или запись (writeAccess), и какие типы объектов являются допустимыми (TPS ManifestSpecification с. 168, TPS ManifestSpecification с. 438).

В манифесте развертывания целевая конфигурация (Target Configuration) связывает абстрактные прототипы портов с конкретными физическими ресурсами платформы (AUTOSAR AP TPS ManifestSpecification с. 649). Элемент метамодели CryptoKeySlotToPortPrototypeMapping сопоставляет порт процесса с CryptoKeySlot, объявленным в CryptoModuleInstantiation машины (TPS ManifestSpecification с. 614, TPS ManifestSpecification с. 646). Аналогичным образом CryptoCertificateToPortPrototypeMapping сопоставляет сертификаты (TPS ManifestSpecification с. 655). Во время выполнения путь порта в манифесте представляет собой ara::core::InstanceSpecifier, который код приложения передает в функции загрузки, такие как [SWS_CRYPT_50004] (ManifestSpecification с. 154).

Для платформенных взаимодействий между функциональными кластерами — например, между Communication Management (SecOC, IPsec, TLS) и криптографическим стеком — классические прототипы портов отсутствуют (TPS ManifestSpecification с. 861). Здесь InstanceSpecifier вместо этого формируется элементами, производными от FunctionalClusterInteractsWithFunctionalClusterMapping, например ComKeyToCryptoKeySlotMapping или SecOcJobMapping (TPS ManifestSpecification с. 861, TPS ManifestSpecification с. 864, ManifestSpecification с. 411). Защита персистентности (Persistency Deployment) и контрольные суммы программных кластеров также подключают свои ключи и провайдеры через эти стандартизированные сопоставления манифеста (TPS ManifestSpecification с. 867, TPS ManifestSpecification с. 896).

Поведение при ошибке

Концепция обработки ошибок криптографического модуля следует строгим предписаниям Adaptive Platform для отказоустойчивого кода без исключений (noexcept) (SWS Cryptography с. 145). Все синхронные операции возвращают ошибочные ситуации через обобщенный тип результата ara::core::Result<T, ara::core::ErrorCode> (SWS Cryptography с. 208). Коды ошибок закреплены в отдельном домене ошибок, представляемом через [SWS_CRYPT_19902]; его имя можно запросить через [SWS_CRYPT_19950], а текстовое описание ошибки — через [SWS_CRYPT_19953]. Для приложений, явно использующих обработку исключений, стек предоставляет тип исключения CryptoException ([SWS_CRYPT_19906]) и вспомогательную функцию [SWS_CRYPT_19954].

Типичные функциональные коды ошибок включают нарушения контекста, такие как CryptoErrc::kUninitializedContext, если криптографические операции инициируются до вызова SetKey(), или CryptoErrc::kInvalidInputSize, если переданные входные буферы данных не соответствуют требуемому растру блоков (SWS Cryptography с. 208). При операциях сериализации и преобразования CryptoErrc::kUnknownIdentifier сигнализирует о неподдерживаемых значениях аргументов, а CryptoErrc::kIncompatibleArguments — о несовместимых комбинациях параметров (SWS Cryptography с. 145). При доступе к ключевым ресурсам стек предотвращает несанкционированный доступ возвратом kAccessViolation (SWS Cryptography с. 87). При синтаксическом анализе некорректных пользовательских расширений сертификатов X.509 парсер аварийно прерывает работу с ошибкой CryptoErrc::kRuntimeFault (SWS Cryptography с. 280, SWS Cryptography с. 356).

Чтобы восстановить определенное состояние в контексте после возникшей ошибки и избежать утечек памяти или зависших потоковых буферов в демоне, вызывающая сторона должна очистить контекст. Это происходит либо целенаправленно путем вызова Cancel() ([SWS_CRYPT_50046], [SWS_CRYPT_50089]), в результате чего незавершенные преобразования отбрасываются, либо через Reset() ([SWS_CRYPT_50212]), что полностью возвращает контекст в состояние, предшествующее привязке ключа (EXP SWArchitecture с. 100).

Дальнейшие подробные доказательства

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

• Глобальные точки входа и фабрики: спецификации [SWS_CRYPT_20099] (LoadCryptoProvider) и [SWS_CRYPT_40099] (LoadX509Provider) определяют нормативный доступ к двум первичным доменам провайдеров (SWArchitecture с. 71, SWS Cryptography с. 39).
• Хранение ключей и привязка портов: функции [SWS_CRYPT_50004] (LoadKeySlot) и [SWS_CRYPT_50005] (LoadWriteableKeySlot) обязательно реализуют взаимодействие между моделированием портов в манифесте и изолированным физическим доступом к хранилищу в KSP (SWS Cryptography с. 87, AUTOSAR AP TPS ManifestSpecification с. 649).
• Фабрики примитивов и контекстов: группа интерфейсов вокруг [SWS_CRYPT_20745] (CreateAuthCipherCtx), [SWS_CRYPT_20756] (CreateSignerPrivateCtx) и [SWS_CRYPT_20757] (CreateVerifierPublicCtx) определяет динамическое создание стандартизированных конечных автоматов для криптографических заданий (AUTOSAR AP EXP SWArchitecture с. 99, AUTOSAR AP TR SystemTests с. 164).
• Валидация X.509 и проверка отзыва: с помощью [SWS_CRYPT_50125] (CreateCertificateValidationCtx), [SWS_CRYPT_50122] (ValidateCertificate), [SWS_CRYPT_50183] (ImportCrl) и [SWS_CRYPT_50124] (AddOcspResponse) нормируется полная цепочка проверки PKI, отвечающая требованиям автомобильной отрасли (AUTOSAR AP TR SystemTests с. 194, EXP SWArchitecture с. 116).