Глава 7. Безопасность и шифрование

7.1 Модель безопасности

Реализация DTP MUST обеспечивать сквозное шифрование. Модель безопасности MUST удовлетворять следующим инвариантам:

1. Только целевой экземпляр iFay MUST иметь возможность расшифровать полученный Payload.
2. Среда выполнения FayGer MUST NOT иметь доступа к данным в открытом виде ни при каких обстоятельствах.
3. Промежуточные сетевые узлы MUST NOT иметь возможности читать Payload в открытом виде.
4. Реализация DTP MUST NOT управлять ключами шифрования самостоятельно.

7.2 Область шифрования

Область шифрования MUST быть строго ограничена Payload в составе LogicalFrame.

7.2.1 Содержимое, которое MUST быть зашифровано

Следующие данные MUST быть зашифрованы:

• Поле payload LogicalFrame (т.е. поле data Fragment, а также — когда передаётся в виде фрейма — содержимое RequestFrame, ResponseFrame и ControlFrame).

7.2.2 Содержимое, которое MUST NOT быть зашифровано

Следующие данные MUST NOT быть зашифрованы и MUST передаваться в открытом виде:

• header LogicalFrame (включая protocolVersion, frameType, fragmentId, agreementId, originTimestamp, dagDependencies, encryptionMetadata и sequenceNumber).

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

7.3 Управление ключами

7.3.1 Источник ключа

Реализация DTP MUST использовать ключ, заранее согласованный через CAP. В частности:

1. CAP MUST завершить аутентификацию и обмен ключами на этапе установления соединения.
2. Реализация DTP MUST использовать sessionKey, предоставленный CAP, для шифрования/расшифровки Payload.
3. Реализация DTP MUST NOT генерировать, согласовывать или обмениваться ключами шифрования самостоятельно.

7.3.2 Интерфейс CAPContext

Реализация DTP MUST получать контекст, предоставляемый CAP, через следующий интерфейс:

interface CAPContext {
  identity: string;
  sessionKey: Uint8Array;
  verified: boolean;
}

Поле	Нормативное требование
identity	MUST быть идентификатором личности пира
sessionKey	MUST быть последовательностью байтов сеансового ключа, согласованного через CAP
verified	MUST отражать статус верификации CAP

7.3.3 Предусловия CAP

Реализация DTP MUST проверять CAPContext перед началом передачи данных:

1. Если verified === false, MUST отказать в отправке любого data-фрейма и вернуть ошибку KEY_NOT_READY (2002).
2. Если sessionKey пуст или имеет некорректную длину, MUST вернуть ошибку KEY_NOT_READY.
3. Передача переговорных фреймов (Request_Frame, Response_Frame) аналогично подчиняется этому предусловию.

7.4 Метаданные шифрования

Заголовок каждого LogicalFrame MUST содержать EncryptionMetadata:

interface EncryptionMetadata {
  algorithm: string;
  keyVersion: number;
}

7.4.1 Идентификаторы алгоритмов

Поле algorithm MUST быть строкой-идентификатором алгоритма шифрования. SHOULD использовать одно из следующих стандартизованных названий:

Идентификатор	Алгоритм	Статус
"AES-256-GCM"	AES-256 в режиме Galois/Counter	RECOMMENDED
"ChaCha20-Poly1305"	ChaCha20 с Poly1305	RECOMMENDED
"AES-128-GCM"	AES-128 в режиме Galois/Counter	MAY использоваться

Реализация MUST поддерживать как минимум один из AES-256-GCM и ChaCha20-Poly1305. RECOMMENDED поддерживать оба для повышения совместимости.

Реализация MUST NOT использовать:

• Режим ECB (небезопасен)
• Неаутентифицированные режимы шифрования (CBC, CTR без MAC)
• Алгоритмы с известными слабостями (DES, 3DES, RC4)

7.4.2 Номер версии ключа

keyVersion MUST быть неотрицательным целым числом, используемым для поддержки ротации ключей:

1. При запуске CAP ротации ключей keyVersion нового ключа MUST быть строго больше предыдущей версии.
2. Получатель MUST выбирать соответствующий ключ для расшифровки на основе keyVersion.
3. Реализация SHOULD сохранять как минимум одну предыдущую версию ключа для поддержки Fragment, находящихся в пути.

7.5 Согласованность шифрования при двойном проходе

Реализация MUST удовлетворять следующим свойствам согласованности шифрования при двойном проходе:

1. Шифрование с последующей расшифровкой с использованием корректного ключа (совпадающего с ключом, использованным отправителем) MUST давать вывод, побитно идентичный исходному Payload.
2. Расшифровка с использованием некорректного ключа MUST завершаться неудачно и MUST возвращать ошибку DECRYPTION_FAILED (2001).
3. При сбое расшифровки реализация MUST NOT возвращать частичные результаты расшифровки или повреждённые данные.

7.6 Расшифровка на стороне терминала

Когда терминал выступает в роли получателя (сценарий инжекции данных):

1. DTP_Slave MUST использовать для расшифровки ключ, представленный терминалом на этапе установления соединения CAP.
2. Этот ключ MUST соответствовать приватному ключу/сеансовому ключу, который терминал представил в CAP.
3. Терминал MUST NOT принимать результат расшифровки любого другого ключа.

7.7 Обработка сбоев расшифровки

Реализация MUST обрабатывать сбои расшифровки в соответствии со следующими правилами:

1. Единичный сбой расшифровки: отбросить фрейм и отправить уведомление об ошибке DECRYPTION_FAILED (2001).
2. Последовательные сбои расшифровки, превышающие пороговое значение (определяемое реализацией, RECOMMENDED значение 3): a. SHOULD инициировать повторное согласование ключей через CAP. b. SHOULD уведомить приложение верхнего уровня об аномалии безопасности.
3. Реализация MUST NOT повторять попытку расшифровки одного и того же фрейма бесконечно после нескольких сбоев.

7.8 Митигация угроз безопасности

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

Угроза	Механизм митигации
Перехват методом «человек посередине»	Сквозное шифрование Payload
Подсматривание со стороны FayGer	Шифрование Payload; FayGer видит только шифротекст
Утечка ключей	Механизм версий ключей поддерживает ротацию ключей
Подделка личности	Делегируется CAP для верификации
Атаки воспроизведения	Монотонно возрастающие порядковые номера + привязка к Session
Подделка фреймов	Алгоритмы аутентифицированного шифрования (AEAD)

7.9 Защита от воспроизведения

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

1. Монотонно возрастающие порядковые номера: получатель MUST отвергать фреймы, чей порядковый номер меньше или равен наибольшему подтверждённому порядковому номеру (за исключением сценариев возобновления).
2. Привязка к Session: пространство порядковых номеров MUST быть привязано к конкретной Session. Новая Session MUST сбрасывать порядковый номер.
3. AEAD-аутентификация: алгоритм шифрования MUST обеспечивать аутентификацию сообщений (GCM, Poly1305 и т.д.).

7.10 Приватность метаданных

Реализация SHOULD учитывать, что метаданные в открытом виде в заголовке фрейма MAY раскрывать следующую информацию:

• Идентификаторы участников коммуникации (коррелируемые через agreementId)
• Временные паттерны коммуникации (через originTimestamp и sequenceNumber)
• Частота передачи данных (через интервалы между фреймами)

Реализация MAY улучшать приватность метаданных через:

1. Включение трафик-паддинга (определяется реализацией).
2. Использование транспортного уровня с обфускацией (например, ECH на основе TLS 1.3).

Однако настоящая спецификация NOT REQUIRE от реализации обеспечивать защиту приватности метаданных.