Команда обновления данных требует уточнения в случае многократного вызова

[andrewkostevich]

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

Рекомендуется указать обязательное использование цепочки команд только с последовательными смещениями.

[olegotory]

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

Сценарий записи следующий:

• Выбирается файл командой Select File.
• Необходимое количество раз вызывается Update binary (без использования цепочки команд).

[andrewkostevich]

Без цепочки команд невозможно определить корректность записи длинного файла: был ли он записан весь (пришла последняя APDU в цепочке) или запись оборвалась.

[olegotory]

Можно определить: если все команды отработали успешно.

ср, 27 февр. 2019 г. в 17:30, andrewkostevich notifications@github.com:

Без цепочки команд невозможно определить корректность записи длинного файла: был ли он записан весь (пришла последняя APDU в цепочке) или запись оборвалась.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bcrypto/btok/issues/46#issuecomment-467882620, or mute the thread https://github.com/notifications/unsubscribe-auth/Ahz2MVFNtTVwAjQ7ov88cnWljFQ4Ew6tks5vRpZwgaJpZM4bUkrU .

[andrewkostevich]

Клиентская программа хотела записать 257 байт: отправила первую APDU команду с 255 байтами и тут пользователь закрыл клиентскую программу. Карта записала первые 255 байт и считает что файл создан и длина его 255. Считаем это штатным поведением?

[olegotory]

Все элементарные файлы имеют фиксированный размер, который устанавливается разработчиком на этапе производства (первоначально туда записываются нужные данные или просто нулевые байты). Размер элементарных файлов в ходе эксплуатации не меняется. В нашем случае все данные, записваемые в элементарные файлы кодируются, что позволяет определить размер записанных данных в файле (если данных меньше, чем размер файла). Я не встречал, чтобы команда Update binary могла использоваться в режиме цепочной обработки. Если предположить, что команда Update binary используется в режиме цепочной обработки, то тогда:

1. В карте должен выделяться буфер, в который будут записываться данные и только при вызове последней команды цепочки должна производиться перезапись файла (это еще можно сделать, так как размер файла известен).
2. Карта должна анализировать корректность задания смещений и длин данных во всех командах цепочки. Получается сложная логика для карты, не думаю что такая логика предусмотрена для Update binary. Для команды я встречал только следующие коды ошибок, которые связаны со смещениями и длиной данных: ’67 00’ Wrong length (Lc=0, P1||P2 + Lc outside the EF) ; ‘6B 00’ Wrong parameter P1-P2 (offset outside the EF).

Отмечу, что в ISO 7816-4 для команды Update binary написано: "The command initiates the update of bits already present in an EF with the bits given in the command data field. When the process is completed, each bit of each specified data unit will have the value specified in the command data field. " Я понимаю этот текст так, что при каждом вызове команды мы перезаписываем определенное содержимое файла.

[olegotory]

Предложение: Написать в стандарте, какие команды можно выполнять в режиме цепочной обработки. Например, как в "Technical Guideline TR-03110. Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token – Part 3: Common Specifications" написано: "Command chaining is only used for the General Authenticate command". В нашем стандарте сейчас обязательно в режиме цепочной обработки используется команда "General Authenticate". Дополнительно в стандарте цепочку разрешается использовать для "PSO:Verify Certificate" (отмечу, что TR-03110-3 цепочку для данной команды не разрешается использовать). Есть предложение @andrewkostevich по цепочке для "Update binary" (см. обсуждение выше). Цепочка для "Update binary" позволит более надежно записывать данные в файл (т.е. данные будут записаны в файл только в случае, если все команды цепочки отработают успешно), но с другой стороны такая цепочка усложняет логику карты. Я против цепочки для "Update binary". Для id-карты цепочка "Update binary" может потребоваться только для записи сертификата ключа подписи. Если записывать сертификат без цепочки, то всегда можно понять, записался он целиком или только частично, более того, при проверке сертификата будет обнаружено, что сертификат был записан некорректно.

[andrewkostevich]

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

Вопрос возник из конкретной задачи установки сертификата в программу eSign:

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

Как мы видим, в случае с сертификатом все предположения нарушены.

Другие данные также имеют переменную длину: например, прописка, изображение подписи (хотя они не является обязательными для хранения). И тоже может потребовать многократный вызов команды.

Цепочка команд решает эту проблему.

Если команда Update binary не используется в цепочке, но это лишь говорит, что правильнее было бы использовать команду Write Binary.

Предложение: изменить Update binary на Write Binary и указать на режим цепочки для Write Binary

[andrewkostevich]

Если записывать сертификат без цепочки, то всегда можно понять, записался он целиком или только частично,

Как?

более того, при проверке сертификата будет обнаружено, что сертификат был записан некорректно.

Это будет обнаружено не теми (проверяющей стороной) и не в нужное время (не в момент установки сертификата/выработки ЭЦП)

[olegotory]

Я не понял, какие предположения нарушены. В СТБ 34.101.78 сертификаты отпрофилированы, размер файла для сертификата можно оценить. Длину файла для прописки (если такие данные будут) также можно оценить. Фиксированные размеры файлов значительно упрощают логику работы карты.

Команда write binary не позволяет несколько раз записать данные в файл. Фактически можно записать только один раз.

Ответ на "как?" За запись данных отвечает клиентская программа или терминал. Они сами делят данные на последовательные части и определяют нужные смещения. После этого для каждой части вызывают команду. Если все команды отработали успешно, то данные записаны корректно, если какая-либо часть не записалась, то повторяется запись части или выдается предупреждение о невозможности записать данные (владелец карты должен повторить процедуру). Да, возможно, что данные будут записаны некорректно, но: 1)владелец был предупрежден; 2) к нарушению безопасности это не приведет.

Насколько я помню сейчас ОАЦ склоняется к варианту, при которм сертификат ключа подписи будет записываться при выпуске карты. В этом случае всегда можно записать данные корректно или признать карту нерабочей. Если прописка будет, то за ее запись отвечает терминал с определенными правами (скорее всего специальный орган, как сейчас с паспортом) и он должен будет записать прописку или признать карту нерабочей.

[andrewkostevich]

В СТБ 34.101.78 сертификаты отпрофилированы, размер файла для сертификата можно оценить.

Размер сертификата зависит от длины фамилии, имени, отчества, поэтому размер сертификата неизвестен

Команда write binary не позволяет несколько раз записать данные в файл. Фактически можно записать только один раз.

Синтаксис write binary и update binary практически идентичны, write binary включает в себя update binary

За запись данных отвечает клиентская программа или терминал.

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

Насколько я помню сейчас ОАЦ склоняется к варианту...

Мы договорились не касаться инфраструктуры, а рассматривать только архитектуру (#37). С точки зрения архитектуры, при многократном вызове команды записи в случае обрыва записи карта переходит в неверное состояние (данные повреждены) и карта не знает что ее данные повреждены. В случае цепочки команд карта знает что ее данные повреждены.

[olegotory]

Размер сертификата зависит от длины фамилии, имени, отчества, поэтому размер сертификата неизвестен

Для сертфиката физического лица согласно СТБ 34.101.78 используются атрибуты: commonName -- максимальный размер 64; surname -- максимальный размер 128; givenName -- максимальный размер 128; serialNumber -- максимальный размер 64; countryName -- размер 2. Остальные поля сертификата можно легко оценить также, т.е. можно легко оценить максимальный размер сертификата и, следовательно, размер файла.

У нас получается пустое обсуждение. Я не понял предложений @andrewkostevich ... В чем они состоят конкретно и какой в этом смысл?

Нужно указать для update binary, что при использовании цепочки команд должны использоваться с последовательные смещения и карта должна контролировать корректность смещений в цепочке и возвращать ошибку при нарушении?

[andrewkostevich]

легко оценить максимальный размер сертификата Все элементарные файлы имеют фиксированный размер

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

Предложение: изменить Update binary на Write Binary и указать на режим цепочки для Write Binary только с последовательными смещениями. В этом случае при многократном вызове команды записи в случае обрыва записи карта знает что ее данные повреждены

[olegotory]

Это два противоречивых утверждения: размер или фиксированный или переменный (но не более заданного).

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

Изменить Update binary на Write Binary ...

В iso 7816-4 для Write Binary написано: The command initiates one of the following operations into an EF according to the file attributes:  the write-once of the bits given in the command data field (the command shall be aborted if the string of data units is not in the logical erased state);  the logical-OR of the bits already present in the card with the bits given in the command data field (the logical erased state of the bits of the file is zero);  the logical-AND of the bits already present in the card with the bits given in the command data field (the logical erased state of the bits of the file is one).

Получается, что при перезаписи файлов нам нужно будет перезаписывать с использованием "logical-OR" или "logical-AND"... Это только все усложняет. Чем она лучше чем update binary? Если вводится команда WRITE BINARY, то нужна будет команда ERASE BINARY.

в случае обрыва записи карта знает что ее данные повреждены

Что должна делать карта в этом случае (например, когда карту выдернули до выполнения последней команды цепочки)? Не должна позволять читать данные с файла? А писать можно туда? Что должен делать пользователь, если данные не читаются? В чем для владельца выгода?

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

[andrewkostevich]

Предлагаются файлы переменной длины (но не более заданного)? Для чего это нужно делать?

Согласно СТБ 34.101.78 сертификаты имеют переменную длину (есть ограничение на их длину сверху, но точная длина сертификата априорно не известна). Так что файл сертификата имеет переменную длину. Это объективная реальность данная нам в ощущении.

Тикет был закрыт: обсуждение не требуется.