|
В этом приложении к протоколу CWMP [1] описывается формат подписанного пакета, который может использоваться для защищенной загрузки файлов в принимающее устройство. Этот формат позволяет инкапсулировать один или несколько файлов в один подписанный пакет. Формат пакета позволяет получателю аутентифицировать источник, и в пакете содержатся инструкции для распаковки пакета и установки его содержимого.
Примечание: расшифровку незнакомых терминов и аббревиатур см. в разделе "1.6. Терминология" статьи [16], там также приведен перевод общего описания протокола CWMP/TR-069 из документации [1].
Формат подписанного пакета предназначен для использования в загрузках файлов с сервера по протоколам HTTP, HTTPS или FTP, или другими способами передачи файла из удаленного или локального источника.
[E.2. Структура Signed Package Format]
Базовый формат файла подписанного пакета показан на рис. 8.
Рис. 8. Signed Package Format.
Общее описание каждого из компонентов подписанного пакета приведено в таблице 65.
Таблица 65. Краткое описание составляющих компонентов подписанного пакета.
| Компонент |
Описание |
| Header |
Заголовок. Блок данных фиксированной длины, содержащий преамбулу, версию формата, длины компонентов списка команд и полезной нагрузки. |
| Command list |
Список команд. Содержит последовательность инструкций, которым необходимо следовать при распаковке и установке содержимого полезной нагрузки (файлов) пакета. Каждая команда кодируется в форме тип-длина-значение (type-length-value, TLV). |
| Signatures |
Цифровые подписи. Эта секция пакета содержит блок цифровой подписи (PKCS #7 digital signature block), содержащий ноль или большее количество цифровых подписей (digital signature), как описано в секции E.5. |
| Payload files |
Файлы полезной нагрузки. Эта секция пакета содержит один или большее количество файлов для установки в соответствии с инструкциями в списке команд.
Этот документ не определяет никакие специальные форматы файлов полезной нагрузки. |
E.2.1. Соглашения по кодированию. В этом документе используются следующие соглашения кодирования, если специально не указано нечто иное:
• Multi-octet (многобайтные) числовые значения кодируются в сетевом порядке байт (network byte order, big endian format).
• Имена файлов или директорий указываются в формате UNIX (например "/var/log/firmware.bin").
[E.3. Формат заголовка]
Заголовок подписанного пакета составляет структуру размером в 24 октета (байта). Формат заголовка определен в таблице 66.
Таблица 66. Signed package header format.
| Поле |
Тип |
Описание |
| Preamble |
8 байт |
Фиксированная последовательность октетов следующих HEX-значений:
32 57 49 52 45 5F 53 50
Интерпретатор формата подписанного пакета ДОЛЖЕН проверить преамбулу, чтобы она содержала именно такую последовательность данных. |
| Major version |
32-битное целое |
Значение, показывающее major-составляющую версии формата пакета. Реализация, удовлетворяющая этой спецификации, ожидает major-версию 1 (один).
Изменения в major-версии обозначают несовместимые изменения для этого формата. |
| Minor version |
32-битное целое |
Значение, показывающее minor-составляющую версии формата пакета. Реализация, удовлетворяющая этой спецификации, ожидает minor-версию 0 (ноль).
Изменения в minor-версии обозначают совместимые изменения для этого формата. Реализация, поддерживающая эту версию спецификации, должна быть в состоянии обеспечить интерпретацию пакетов, закодированных с другим значением minor-версии. |
| Command list length |
32-битное целое |
Длина списка команд в байтах. Длина списка команд ДОЛЖНА быть меньше 216. |
| Payload length |
32-битное целое |
Длина полезной нагрузки в байтах, учитывающая все находящиеся в полезной нагрузке файлы. |
[E.4. Формат списка команд]
Каждая команда в списке имеет формат, показанный в таблице 67.
Таблица 67. Command format.
| Поле |
Тип |
Описание |
| Type |
32-битное целое |
Задает определенную команду. |
| Length |
32-битное целое |
Задает длину в байтах поля Value. Общая длина команды равна Length + 8 байт. |
| Value |
Зависимый |
0 или большее количество байт параметров, связанных с командой определенного типа. |
Если получатель этого формата файла находит неизвестное ему значение Type, он ДОЛЖЕН игнорировать команду и продолжить анализ оставшейся части пакета, используя значение Length, чтобы перейти к следующей команде, если таковая имеется.
E.4.1. Типы команд. Список команд содержит команды двух типов: параметры пакета и предпринимаемые действия. Примеры параметров пакета включают software version содержащегося ПО, или таймаут для остальной части загрузки. Примеры действий: добавление (add), удаление (delete) и перемещение (move). Действия, предпринимаемые совместно в порядке, указанном списком команд, определяют последовательность изменений файловой системы, необходимых для распаковки и установки содержащихся в полезной нагрузке файлов.
У связанных с файлами команд есть 2 варианта: один работает с явными файлами, и другой, который работает с файлами определенных версий (versioned file). Имя versioned-файла фиксировано "базой" длиной до 8 символов, и "расширением" из 3 символов. Каждый раз, когда содержимое versioned-файла обновляется, его расширение меняется на новое значение, показывающее версию файла. Поэтому, если при апгрейде нужно заменить versioned-файл, необходимо удалить любой существующий файлом с тем же базовым именем, но другим расширением.
Специальные команды, определенные этой спецификацией, перечислены в таблице 68.
Таблица 68. Общая информация по типам команд.
| Тип |
Имя команды |
| 0 |
End |
| 1 |
Extract File |
| 2 |
Extract Versioned File |
| 3 |
Add File |
| 4 |
Add Versioned File |
| 5 |
Remove File |
| 6 |
Remove Versioned File |
| 7 |
Remove Sub-Tree |
| 8 |
Move File |
| 9 |
Move Versioned File |
| 10 |
Version |
| 11 |
Description |
| 12 |
Recoverable Timeout |
| 13 |
Unrecoverable Timeout |
| 14 |
Initial Timeout |
| 15 |
Initial Activity Timeout |
| 16 |
Reboot |
| 17 |
Format File System |
| 18 |
Minimum Version |
| 19 |
Maximum Version |
| 20 |
Role |
| 21 |
Minimum Non-Volatile Storage |
| 22 |
Minimum Volatile Storage Size |
| 23 |
Reserved |
| 24 |
Reserved |
| 25 |
Required Attributes |
| 1000 .. 9999 |
Vendor-specific commands |
E.4.2. Команда End. Эта команда обозначает конец списка команд. Она необязательно должна присутствовать в списке команд, однако если она встретилась, то получатель ДОЛЖЕН прекратить парсинг остальной части списка команд в пакете.
Параметр Length для этой команды ДОЛЖЕН быть 0 (ноль), показывая тем самым, что дальше нет поля Value.
E.4.3. Команды Extract и Add. Команды распаковки (extract) и добавления (add) включают Extract File, Extract Versioned File, Add File и Add Versioned File.
Команды extract инструктируют получателя пакета удалить любые существующие файлы с таким же именем, и заменить его на файл, указанный в полезной нагрузке.
Команды add инструктируют получателя сначала проверить существующий файл с таким же именем, и установить новый файл только тогда, когда не найден существующий файл с таким же именем.
Для вариантов этих команд, относящихся к versioned-файлу, перечисленные выше операции вышеуказанные операции рассматривают существующий файл как любой файл с тем же базовым именем, что и указанный файл. Т. е. команда Extract Versioned File удалит все существующие файлы с таким же базовым именем и любым расширением перед тем, как установит новый файл. Подобным образом команда Add Versioned File проверит существование любого файла с таким же базовым именем, как у указанного файла, независимо от расширения, и устанавливает файл только в том случае, если такой файл не найден.
Когда новый файл должен быть помещен в директорию, которая не существует, получатель ДОЛЖЕН создать требуемую директорию.
Все команды extract и add содержат в команде порцию Value. Формат этой информации определен в таблице 69.
Таблица 69. Формат Value для команд extract и add.
| Поле |
Тип |
Описание |
| Flags |
32-битное целое |
Битовое поле, определенное следующим образом:
Bit 0 (LSB): Unsafe Flag. 1 (единица) в этом флаге показывает, что если эта команда завершилась успешно, но последующая команда в списке завершилась неудачей, то получатель останется в небезопасном состоянии (unsafe state), и ДОЛЖЕН следовать своим процедурам для восстановления своей файловой системы в известное безопасное состояние (known safe state).
Все другие биты зарезервированы, ДОЛЖНЫ быть установлены в 0 (ноль) и ДОЛЖНЫ быть игнорированы получателем. |
| Path Offset |
32-битное целое |
Смещение в байтах от начала поля Value до поля Path в этой команде. |
| Path Length |
32-битное целое |
Длина поля Path в байтах. |
| Hash Type |
32-битное целое |
Тип алгоритма хеша, используемого в создании поля Hash. В настоящий момент определены следующие значения:
1 = SHA-1. Когда установлено это значение, поле Hash содержит 20-байтный SHA-1 хеш указанного файла. Значение Hash Length в этом случае ДОЛЖНО быть установлено в значение 20 (десятичное).
Все другие значения зарезервированы. |
| Hash Offset |
32-битное целое |
Смещение в байтах от начала поля Value до поля Hash в этой команде. |
| Hash Length |
32-битное целое |
Длина поля Hash в байтах. |
| File Offset |
32-битное целое |
Смещение в байтах от начала порции полезной нагрузки пакета до начала указанного файла. |
| File Length |
32-битное целое |
Длина полезной нагрузки файла в байтах. Это актуальное содержимое файла, находящееся в порции полезной нагрузки файла пакета. |
| Path |
Строка длиной Path Length |
Путь указанного файла, включающий дерево директорий и имя файла. |
| Hash |
Строка байт длиной Hash Length |
Хеш от полезной нагрузки файла, вычисленный алгоритмом хеша, определенным в поле Hash Type. Хеш полезной нагрузки файла включен в команду, потому что сигнатуры проверяют только заголовок пакета и список команд. Включением хеша файла в команду сигнатура гарантирует достоверность содержимого файла. |
E.4.4. Команды Remove. Это команды удаления, которые включают Remove File, Remove Versioned File и Remove Sub-Tree.
Команда Remove File удалит файл по указанному пути, если такой файл существует.
Команда Remove Versioned File удалит все файлы с тем же базовым именем, что и указанный файл, независимо от расширения.
Команда Remove Sub-Tree удалит все файлы и директории ниже и включая по указанному пути.
Во всех командах remove присутствует информация в порции Value команды. Формат этой информации определен в таблице 70.
Таблица 70. Формат поля Value для команд remove.
| Поле |
Тип |
Описание |
| Flags |
32-битное целое |
Битовое поле, определенное следующим образом:
Bit 0 (LSB): Unsafe Flag. 1 (единица) в этом флаге показывает, что если эта команда завершилась успешно, но последующие команды в списке команд потерпели неудачу, то устройство получателя останется в небезопасном состоянии (unsafe state), и ДОЛЖНО следовать своим процедурам для восстановления своей файловой системы в известное безопасное состояние (safe state).
Все другие биты зарезервированы, ДОЛЖНЫ быть установлены в 0 (ноль) и ДОЛЖНЫ быть игнорированы получателем. |
| Path Offset |
32-битное целое |
Смещение в байтах от начала поля Value до поля Path в этой команде. |
| Path Length |
32-битное целое |
Длина поля Path в байтах. |
| Path |
Строка длиной Path Length |
Путь до указанного файла или имя директории. |
E.4.5. Команды Move. К командам переименования (move) относятся Move File и Move Versioned File.
Команда Move File переименовывает файл в новое имя, указанное в этой команде. Если указанный путь назначения это другая директория, то файл перемещается в указанную директорию назначения.
Команда Move Versioned File переместит файл с совпавшим базовым именем, указанным в пути источника, независимо от расширения. Если в указанной директории присутствует несколько таких файлов, то только один из файлов переименовывается, а остальные файлы удаляются. Если строка расширения versioned-файла это десятичное число, то файл с самым маленьким значением этого числа перемещается, и остальные файлы удаляются.
Во всех случаях, если файл с таким же именем уже существует, которое указано как путь файла назначения, команды move перезапишут этот файл.
Если указанный в команде move файл источника не существует, то никакие действия не производятся, и получатель продолжает обрабатывать остальные команды в списке команд.
Все move-команды содержат в себе порцию Value. Формат этой информации определен в таблице 71.
Таблица 71. Формат поля Value для команд move.
| Поле |
Тип |
Описание |
| Flags |
32-битное целое |
Битовое поле, определенное следующим образом:
Bit 0 (LSB): Unsafe Flag. 1 (единица) в этом флаге показывает, что если эта команда завершилась успешно, но последующие команды в списке завершились неудачей, то устройство получателя останется в небезопасном состоянии (unsafe state), и ДОЛЖНО следовать своим процедурам для восстановления своей файловой системы в известное безопасное состояние (safe state).
Все другие биты зарезервированы, ДОЛЖНЫ быть установлены в 0 (ноль) и ДОЛЖНЫ быть игнорированы получателем. |
| Source Path Offset |
32-битное целое |
Смещение в байтах от начала поля Value до поля Source Path в этой команде. |
| Source Path Length |
32-битное целое |
Длина поля Source Path в байтах. |
| Destination Path Offset |
32-битное целое |
Смещение в байтах от начала поля Value до поля Destination Path в этой команде. |
| Destination Path Length |
32-битное целое |
Длина поля Destination Path в байтах. |
| Source Path |
Строка длиной Source Path |
Путь до файла источника. |
| Destination Path |
Строка длиной Destination Path Length |
Путь места назначения, куда источник должен быть перемещен/переименован. |
E.4.6. Команды Version и Description. Поле обоих команд версии (Version) и описания (Description) содержат одну строкуUTF-8, используемую для информации, отображения или документирования в логе.
Поле Version предназначено, чтобы показать общую версию, связанную с пакетом. Например, если пакет содержит обновление программы (software upgrade, которое может включать в себя несколько отдельных файлов), то поле Version может использоваться, чтобы показать новую версию ПО, связанную с апгрейдом.
E.4.7. Команды Timeout. Команды таймаута включают Initial Timeout, Initial Activity Timeout, Recoverable Timeout и Unrecoverable Timeout.
Команды таймаута задают значение таймаута для продолжения загрузки файла пакета до момента, когда загрузка должна быть закончена. Эти команды предназначены для случая, когда порции команды и сигнатуры пакета загружаются и интерпретируются перед загрузкой остальной части файла пакета. Команды таймаута могут использоваться для управления параметрами таймаута, связанными с процессом загрузки этого типа. Если пакет загружен или принят целиком до интерпретации содержимого пакета, то команды таймаута могут игнорироваться.
Каждая команда таймаута включает информацию в порции Value команды. Формат этой информации определен в таблице 72.
Таблица 72. Формат Value для команд таймаута.
| Поле |
Тип |
Описание |
| Timeout |
32-битное целое |
Значение таймаута в секундах относительно начала операции загрузки пакета. Значение 0 (ноль) показывает бесконечный таймаут. |
Каждая команда таймаута может указать свое отдельное значение, где поле Timeout в такой команде показывает нужное значение таймаута. Использование каждого значения таймаута основано на состоянии получателя, когда он обрабатывает команды, используя модель перехода состояний, показанную на рис. 9. На рисунке показаны переходы состояний, которые происходят при последовательной обработке каждой команды. Для каждой команды состояние остается неизменным до момента, когда происходит один из случаев, указанных стрелками перехода состояния.
Рис. 9. Диаграмма состояний процесса загрузки для модели таймаута.
Показанная выше диаграмма состояний используется во время загрузки, чтобы определить, какое значение таймаута использовать. Определение каждого типа таймаута, связанного с командами таймаута, показаны в таблице 73.
Таблица 73. Определения Timeout-комад.
| Команда |
Описание |
| Initial Timeout |
Эта команда установит таймаут загрузки, используемый в начальном состоянии (Initial State), как показано на рис. 9. Это время отсчитывается с момента начала полной загрузки пакета. |
| Initial Activity Timeout |
Эта команда установит таймаут активности, используемого только во время Initial State, как показано на рис. 9. Таймаут активности измеряется с момента передачи получателю любого последнего пакета данных.
Обратите внимание, что во всех состояниях, кроме Initial State, нет таймаута активности (таймаут активности бесконечный). |
| Recoverable Timeout |
Эта команда установит таймаут загрузки, используемый во время Recoverable State, как показано на рис. 9. Это время отсчитывается с момента начала полной загрузки пакета. |
| Unrecoverable Timeout |
Эта команда установит таймаут загрузки, используемый во время Unrecoverable State, как показано на рис. 9. Это время отсчитывается с момента начала полной загрузки пакета. |
E.4.8. Команда Reboot. Эта команда показывает, что получатель перезагрузится, чтобы процесс инсталляции завершился. Если это используется, то эта команда ДОЛЖНА быть последней в списке команд (кроме End, если она присутствует). Параметр Length для этой команды ДОЛЖЕН быть установлен в 0 (ноль), показывая тем самым, что дальше не идет поле Value.
E.4.9. Format File System. Эта команда показывает, что получатель переформатирует свою файловую систему как часть процесса установки. Если это используется, то подразумевается, что все существующие файлы в файловой системе (или часть файловой системы, относящаяся к процессу инсталляции) очищаются и перезаписываются новыми файлами из пакета.
Параметр Length для этой команды ДОЛЖЕН быть 0 (ноль), показывая тем самым, что дальше не идет поле Value.
E.4.10. Команды Minimum Version и Maximum Version. Эти команды используются для указания диапазона номеров версий ПО, для которых предназначен пакет.
Когда этими командами в пакете указан минимальный и/или максимальный номер версии, получатель НЕ ДОЛЖЕН устанавливать файлы, или предпринимать какие-либо другие действия, указанные в списке команд, если версия ПО получателя выходит за пределы показанного диапазона.
Эта команда может использоваться только в том случае, если формат фактической версии программного обеспечения, связанной с получателем, находится в иерархическом формате, который можно сравнить численно с помощью процедур, описанных ниже.
Команды минимальной и максимальной версий включают информацию в порции Value команды. Формат этой информации показан в таблице 74.
Таблица 74. Формат Value для команд минимума и максимума версий.
| Поле |
Тип |
Описание |
| Version |
Массив 32-битных целых |
Массив целочисленных элементов, показывающих номер версии. Это рассматривается как иерархический номер версии (например "1.0.20.3"), где каждое последующее целое число представляет более младший (more minor) элемент номера версии. |
Для определения, попадает ли версия в указанный диапазон, используется следующая процедура.
Если предоставлена команда Minimum Version, то каждый элемент в массиве Version, начиная с первого (самого старшего) элемента:
1. Если этот элемент актуальной версии получателя больше, чем соответствующий элемент в Minimum Version, то версия получателя удовлетворяет требованию, и процедура обновления выполнится.
2. Если этот элемент актуальной версии получателя меньше, чем соответствующий элемент в Minimum Version, то версия получателя не удовлетворяет требованию. В этом случае получатель НЕ ДОЛЖЕН устанавливать файлы в этом пакете или выполнять любые из оставшихся команд.
3. Иначе (значения равны):
a. Если это последний элемент в массиве, то версия получателя удовлетворяет требованиям, и процедура установки завершится.
b. Иначе (есть еще элементы версий), процедура должна продолжиться с шага 1, извлекая следующий элемент из массива для проверки.
Если предоставлена команда Maximum Version, то каждый элемент в массиве Version, начиная с первого (самого старшего) элемента:
1. Если этот элемент актуальной версии получателя меньше, чем соответствующий элемент Maximum Version, то версия ПО получателя удовлетворяет требованию, и процедура обновления выполнится.
2. Если этот элемент актуальной версии получателя больше, чем соответствующий элемент в Maximum Version, то версия получателя не удовлетворяет требованию. В этом случае получатель НЕ ДОЛЖЕН устанавливать файлы в этом пакете или выполнять любые из оставшихся команд.
3. Иначе (значения равны):
a. Если это последний элемент в массиве, то версия получателя удовлетворяет требованиям, и процедура установки завершится.
b. Иначе (есть еще элементы версий), процедура должна продолжиться с шага 1, извлекая следующий элемент из массива для проверки.
E.4.11. Команда Role. Команда роли используется, чтобы показать целевое приложение или назначение пакета. Он предназначен для указания любых побочных эффектов или постобработки, которые могут потребоваться для конкретного пакета.
Команда роли включает информацию в порцию Value команды. Формат этой информации определен в таблице 75.
Таблица 75. Формат Value для команды роли.
| Поле |
Тип |
Описание |
| Role |
32-битное целое |
Перечисление, показывающее целевое приложение или назначение пакета. Для него определены следующие значения:
1 = Software upgrade (обновление ПО).
2 = Software recovery (восстановление ПО).
3 = Web content (содержимое веб).
4 = Vendor configuration (конфигурация поставщика).
Значения, где в самом старшем байте 0xFF, интерпретируются как vendor-specific Role (роль, определяемая производителем). В этом случае последующие 3 байта содержат OUI (Organizationally Unique Identifier), идентифицирующий вендора, как это определено в [9]. Когда используется это значение, вендор может определить последующие дополнительные аргументы, добавленные в этой команде, чтобы специально идентифицировать роль. Любые дополнительные аргументы интерпретируются специальным способом, задаваемым вендором.
Все другие значения зарезервированы. |
E.4.12. Команды Minimum Storage. Эти команды включают Minimum Volatile Storage Size и Minimum Non-Volatile Storage Size.
Команды минимума хранилища показывают минимальное требование для устройства получателя, чтобы оно могло установить файлы, содержащиеся в пакете. Если эти команды присутствуют, то они показывают минимальное требование для типа хранилища, задаваемое именем команды.
Если устройство получателя не удовлетворяет требованию указанного минимума хранилища, то получатель ДОЛЖЕН не устанавливать любые файлы в пакете, и НЕ ДОЛЖЕН продолжать выполнение команд.
Команды минимума хранилища включают информацию в порции Value команды. Формат этой информации показан в таблице 76.
Таблица 76. Формат Value format для команд minimum storage.
| Поле |
Тип |
Описание |
| Storage Size |
32-битное целое |
Минимальное требуемое хранилище в байтах для типа хранилища, указанного командой. |
E.4.13. Команда Required Attributes. Эта команда используется, чтобы указать дополнительные атрибуты устройства получателя, которые требуются, чтобы можно было считать пакет допустимым для установки.
В одном пакете может быть одна или несколько команд Required Attributes, каждая из которых показывает отдельный класс требуемых атрибутов.
Команда Required Attribute включает информацию в порции Value команды. Формат этой информации определен в таблице 77.
Таблица 77. Формат Value для команды требуемых атрибутов.
| Поле |
Тип |
Описание |
| Defining Entity |
32-битное целое |
Идентификатор, показывающий определитель значений Class и Attribute, используемых в этой команде. Определены следующие значения:
Значение 0 (ноль) показывает определения стандартных Class и Attribute. Стандартные определения это те, что определены этой версией спецификации или её будущими версиями.
Значения, в которых старший байт равен 0xFF, показывают определения Class и Attribute, специфические для вендора. В этом случае последующие 3 байта содержат OUI (Organizationally Unique Identifier), показывающий вендора, как это определено в [9].
Если получатель обрабатывает команду Required Attributes, где предоставлены значения элементов, которые он не распознает, то он должен игнорировать эту команду и продолжить выполнение последующих команд. |
| Class |
32-битное целое |
Перечисление, указывающее критерий, по которому должен сравниваться получатель, чтобы определить, подходит ли этот пакет для этого устройства. Для данного критерия поле Attribute Array указывает конкретные допустимые значения, связанные с этим критерием.
В этой версии спецификации не определены значения стандартного класса. Для вендор-специфичных определяющих сущностей интерпретация значений класса зависит от вендора.
Если получатель обрабатывает команду Required Attributes, где предоставлены значения class, которые он не распознает, то он должен игнорировать эту команду и продолжить выполнение последующих команд. |
| Attribute Array |
Массив 32-битных целых |
Массив атрибутов переменной длины, где каждый атрибут это перечисление определенного допустимого значения для определенного класса.
Если актуальное значение, связанное с устройством получателя, совпадает с любым значением, перечисленным в этом массиве, то получатель удовлетворяет указанному условию. Иначе получатель не удовлетворяет требованию, и пакет НЕ ДОЛЖЕН устанавливаться.
В этой версии спецификации не определены значения стандартных атрибутов. Для вендор-специфичных определяющих сущностей интерпретация значений атрибута зависит от вендора. |
[E.5. Signatures]
Секция сигнатур следует в файле пакета непосредственно за секцией списка команд. Здесь содержится блок цифровой подписи, использующий синтаксис сигнатуры PKCS #7 [14].
В частности, блок сигнатур включает ровно один объект SignedData PKCS # 7, который содержит ноль или более сигнатур со следующими ограничениями:
• Сигнатуры являются "external signatures" (внешние сигнатуры). Это означает, что подписанное сообщение не инкапсулируется в объекте SignedData. Вместо этого подписанные данные сообщения состоят из строки байт, сформированной компонентами заголовка и списка команд пакета.
• Элемент contentType для contentInfo ДОЛЖЕН показывать тип "data".
• Элемент content для contentInfo ДОЛЖЕН быть пустым, поскольку это внешняя сигнатура, и данные сообщения находятся вне самой сигнатуры.
• Для каждой сигнатуры ДОЛЖЕН использоваться digestAlgorithm типа SHA-1.
• Для каждой сигнатуры ДОЛЖЕН использоваться digestEncryptionAlgorithm типа RSA.
• Значение Tag, показывающий Identifier, связанный со всем объектом SignedData целиком, ДОЛЖНО быть меньше или равно 30, что приводит к кодированию Identifier одним байтом.
• Если в блоке сигнатур нет подписей, не будет расширенных сертификатов или списков отзыва сертификатов, то набор SignerInfo будет пустым, а набор digestAlgorithms может быть пустым. Все другие поля в SignedData должны присутствовать как обычно. Обратите внимание, что содержимое пустого блока сигнатур не зависит от содержимого пакета, и поэтому может быть вычислен заранее как фиксированная последовательность байт.
Если блок сигнатур содержит больше одной подписи, то как минимум одна из сигнатур должна быть успешно проверена для получателя, чтобы пакет можно было считать доверенным.
Если получатель пакета ожидает одну или несколько сигнатур, то получатель ДОЛЖЕН проверить сигнатуру или сигнатуры до обработки команд, содержащихся в списке команд. Если ни одна из включенных подписей не прошла проверку, то получатель НЕ ДОЛЖЕН обрабатывать никакие команды в списке команд, или устанавливать любые файлы, содержащиеся в пакете.
Если реализация получателя устроена таким образом, что проверка и обработка списка команд должны выполняться без загрузки всего файла пакета из его источника, то получатель МОЖЕТ предположить, что комбинированная длина заголовка, списка команд и блока сигнатур не больше 150 килобайт.
Обратите внимание, что хотя подписанные данные сообщения включают только заголовок пакета и список команд, подпись гарантирует целостность всего пакета, поскольку все команды, которые ссылаются на файлы полезной нагрузки, включают хеш содержимого файла.
Также имейте в виду, что могут быть добавлены дополнительные сигнатуры в существующий подписанный файл пакета без модификации любой части файла пакета, кроме самого блока сигнатур. Формат пакета структурирован таким образом, чтобы другое содержимое (заголовок, список команд и полезная нагрузка) файла пакета не менялось, если меняется длина блока сигнатур.
[Ссылки]
1. TR-069: CPE WAN Management Protocol https://www.broadband-forum.org/pdfs/tr-069-1-1-0.pdf.
2. TR-046: Auto-Configuration Architecture & Framework https://www.broadband-forum.org/pdfs/tr-046-1-0-0.pdf.
3. TR-062: Auto-Config for the Connection Between the DSL Broadband Network Termination (B-NT) and the Network using ATM (TR-037 update) https://www.broadband-forum.org/pdfs/tr-062-1-0-0.pdf.
4. TR-044: Auto-Configuration for Basic Internet (IP-based) Services https://www.broadband-forum.org/pdfs/tr-044-1-0-0.pdf.
5. RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 http://www.ietf.org/rfc/rfc2616.txt.
6. RFC 2617, HTTP Authentication: Basic and Digest Access Authentication http://www.ietf.org/rfc/rfc2617.txt.
7. RFC 2965, HTTP State Management Mechanism http://www.ietf.org/rfc/rfc2965.txt.
8. Simple Object Access Protocol (SOAP) 1.1 http://www.w3.org/TR/2000/NOTE-SOAP-20000508.
9. Organizationally Unique Identifiers (OUIs) http://standards.ieee.org/faqs/OUI.html.
10. The SSL Protocol, Version 3.0 http://www.netscape.com/eng/ssl3/draft302.txt.
11. RFC 2246, The TLS Protocol, Version 1.0 http://www.ietf.org/rfc/rfc2246.txt.
12. RFC 2132, DHCP Options and BOOTP Vendor Extensions http://www.ietf.org/rfc/rfc2132.txt.
13. XML-Signature Syntax and Processing, http://www.w3.org/2000/09/xmldsig.
14. PKCS #7, Cryptographic Message Syntax Standard http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html, или http://www.ietf.org/rfc/rfc2315.txt.
15. TR-069 cwmp client implementation: open sources comparison site:stackoverflow.com.
16. TR-069: протокол CWMP для управления сетевыми устройствами. |
