Конкретные числа действительно большие. Однако если уж предлагаете какую-то "инновацию" рекомендую предусматривать возможность разрастания базы. Это всегда полезно. И где же обещанный документ, объясняющий мне остальные мои вопросы?
Проблема в том, что любая сделанная на этой основе система через какое-то время просто прекратит свою работу. И просто технически будет невозможно как-то эту работу продолжить: закончится «ёмкость».
Есть несколько вопросов. Может тут хоть кто-то остался, кто сможет на них ответить.
Откуда берется Hash(n, 0) для нулевой транзакции?
Что именно содержится в «нотификате»? Только публичный ключ или что-то ещё? Например в X.509 сертификате предусмотрены политики применения сертификата (ограничения области применения);
Опишите как можно подробнее какой-либо сценарий использования «нотификата». Желательно прямо от процесса подписывания чего-то и до процесса проверки, что вот это что-то подписано именно вот этим «нотификатом» (откуда берется «нотификат» для проверки
На рисунке, поясняющем процесс проверки нулевой транзакции элемент «общедоступный ключ» не нужен: публичный ключ для кошелька берется из поля «signature». Или это какой-то другой «общедоступный ключ»? В этом случае непонятно как он используется для создания нулевой транзакции
Зачем нужна «служебная ключевая пара»? Фактически в статье она применяется как некий идентификатор для определённого кошелька. Однако у самого кошелька уже есть своя ключевая пара. Этот же ключ кошелька может быть использован и для проверки транзакций отличных от нулевой. А если рассматривать использование «служебной пары» как доказательства регистрации субъекта в системе, то для такой регистрации опять можно использовать ключ самого кошелька
Предположим, что злоумышленник зарегистрирован как участник системы. Затем он перехватывает несколько идущих подряд сообщений от другого пользователя и знает несколько предыдущих значений H(n-x). Как мне кажется, в этом случае злоумышленник сможет в новой транзакции от другого пользователя заменить все H корректными значениями и подставить свой публичный ключ. Так злоумышленник может присвоить публичный ключ
Понимают ли создатели данной системы, что «ёмкость» данной системы (количество публичных ключей хранящихся в системе) ограничена 2^256 при применении SHA-256? Эта цифра обусловлена тем, что информация об общедоступных ключах тут хранится в виде хэшей
В начале статьи обозначены две проблемы PKI: централизация системы и начальная аутентификация пользователей. Было предложено решение только для первой проблемы. Использование же blockchain системы ведёт к противоречию: изначально blockchain обезличивает пользователей, а в системе DPKI стоит задача корректной идентификации таких пользователей
Понятно. Так вот в ответе OCSP уже содержится подписанный штамп времени. То есть содержится время, в которое был выдан OCSP response, которое подписывается сертификатом OCSP сервера.
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
Насчёт проверки «средствами сертифицированными ФСБ». Скорее всего здесь идёт речь о создании некой отдельной структуры, которая будет дополнительно собирать деньги с пользователей. Также это может быть ещё одним шагом к тотальному контролю за использованием криптографии: представим, что ключи хранятся только в УЦ, подписи делает только сервис УЦ, подписи проверяет только «доверенная третья сторона». Так что подразумевается только один дополнительный шаг — запрет использования локальных программ создания/проверки подписи. И, кстати, «средства сертифицированные ФСБ» не обязательно должны обладать расширенными средствами проверки подписей. Сертификация предполагает лишь проверку корректности встраивания криптографических средств, не более того.
Вы же по сути предлагаете мне свернуть любую аргументированную дискуссию
Как это видится с моей стороны. Я пишу цитаты из законопроекта. Вы мне пишите другие цитаты, но с каким-то дополнительным трактованием, понятным лишь для вас. Вы каждый раз пытаетесь как-то меня «уколоть» типа я чего-то не знаю да не умею. Я вам каждый раз отвечаю, что и то, и это я знаю, и даже делал сам. Вы продолжайте дискуссию, я только «за». Прерывать не надо :)
Как раз вот это обстоятельство, что третье доверенная сторона провереяет не сертификат на данный момент, а подпись, склоняет меня к тому, что тут законодатель ошибается, имея ввиду как раз OCSP
Доверенная третья сторона оказывает услуги:
а) по подтверждению действительности электронных подписей, задействованных при подписании электронного документа, в том числе установление фактов того, что соответствующие сертификаты были действительны на определенный момент времени
Если этот момент времени описать в терминах метки доверенного времени, то и получится то, о чем я пишу выше.
У меня уже голова кругом от ваших ответов. Вы что имели в виду, когда писали про OCSP? Вас в последней цитате смущает факт, что кроме проверки подписей доверенная сторона ещё и действительность сертификата проверяет или что? Как это «момент времени описать в терминах метки доверенного времени»?
Статья 15 63-ФЗ, которая дополняется подпунктом 2.2, цитату из которого я и привёл, отражает все требования к аккредитованным удостоверяющим центрам. Собственно, сам пункт 2 вот такой:
2. Аккредитованный удостоверяющий центр должен хранить информацию, указанную в части 1 настоящей статьи, в течение срока его деятельности, если более короткий срок не предусмотрен нормативными правовыми актами Российской Федерации. Хранение информации должно осуществляться в форме, позволяющей проверить ее целостность и достоверность
Тут не про «что может делать УЦ», а про что он делать обязан и как хранить. Так вот этот пункт дополняют подпунктом, где говорится, что УЦ должен хранить закрытые ключи пользователей.
Было бы забавно наблюдать, как вы сможете «поручить» УЦ хранить такой ключ
УЦ отзывает существующий сертификат и выдаёт новый, с хранением закрытого ключа в УЦ. Вот и весь процесс. И, кстати, внутри УЦ тоже используется HSM, который тоже типа «с неизвлекаемыми ключами».
Не-не, я сказал что я «с 16-ти летним стажем в области информационной безопасности». Общий у меня 22 года.
прекратите тут давить вашим несуществующим авторитетом
Он очень даже существующий. А чего-то «давить» сами начали: никто ничего не знает, только в теории, я лучше 99% населения. П**здец профи.
и вернитесь в поле аргументированной дискуссии
Собственно вся эта «дискуссия» вышла из-за того, что вы как-то связали понятия «доверенная третья сторона» и «служба штампов времени». Я вам показал прямо определение, прямо из законопроекта, на что вы придумали какую-то ерунду и пытаетесь что-то доказывать. Даже в дополнении к пункту 18.1, на который вы что-то часто напираете, ничего нет про выполнение доверенной третьей стороной функции служба штампов времени. Там только про проверку подписи. Почитайте.
То вы в конца 2019 года открыли для себя «облачную подпись» через чтение законопроекта
Прекратите делать какие-то предположения по поводу что мне известно, а что нет. Я сам писал такие сервисы несколько лет назад, и они даже работали :)
Как раз вот это обстоятельство, что третье доверенная сторона провереяет не сертификат на данный момент, а подпись, склоняет меня к тому, что тут законодатель ошибается, имея ввиду как раз OCSP
Чего? Вы считаете, что надо сертификат на данный момент проверять и всё? Скажу вам, что процесс проверки подписи, особенно «advanced» (CAdES) включает в себя очень доскональную проверку сертификата, однако это достаточно маленький этап всей проверки. OCSP вообще тут упоминать «ни к селу, ни к городу», это просто сервис, его ответ просто встраивается в подпись, если нужно.
Рассудите сами — зачем вообще иначе эта доверенная третья сторона?
Почитайте дополнения к пункту 18.1 в законопроекте, там написано. Вводят сущность, которой поручаются функции доверенной проверки подписей и выдачи квитанций о данной проверке. Ничего более.
Я сам создал рабочий сервис службы штампов времени. Похоже, вы просто не прочитали контекст предыдущих обсуждений. Моё замечание по не корректности относилось к разделению понятий «создание метки доверенного времени» и «доверенная третья сторона». В контексте данного законопроекта термин «доверенная третья сторона» должен быть использован только для проверки метки доверенного времени, к созданию таких меток он отношения иметь не должен.
Боюсь, что здесь узаконивается как-раз процесс полной передачи закрытых ключей только на сторону УЦ. Конечно, «по поручению», но вполне вероятно при заполнении документов это «поручение» будет стоять обязательным пунктом.
метка доверенного времени – достоверная информация в электронной форме о дате и времени подписания электронного документа электронной подписью, создаваемая и проверяемая доверенной третьей стороной
Это не корректная формулировка, и надеюсь она в конечно счёте будет исправлена, так как такие как вы могут её как-раз неправильно трактовать. Здесь подразумевается, что метка времени просто проверяется доверенной третьей стороной. И ещё раз — термин «доверенная третья сторона» не имеет никакого отношения к службе штампов времени.
Они же делают OCSP, о котором по сути написал вы
Товарищ «энтузиаст», OCSP — это сервис проверки «не отозванности» сертификата в данный момент. Он не проверяет никакой подписи.
Вы знаете вопрос только в теории
Вы бы хоть посмотрели, кто я такой, прежде чем это всё писать. Я программист с 16-ти летним стажем в информационной безопасности. Я ведь не «энтузиаст», я этим зарабатываю.
Интересная информация из законопроекта, не упомянутая в данной статье.
Уполномоченные УЦ по поручению владельца квалифицированного сертификата осуществляют: хранение ключа электронной подписи, ключ проверки которой содержится в квалифицированном сертификате с обеспечением его защиты от компрометации и (или) несанкционированного использования, в том числе, создание при помощи указанного ключа подписи по поручению владельца квалифицированного сертификата электронной подписи с использованием средств электронной подписи, имеющих подтверждение соответствия требованиям, установленным в соответствии с пунктом 2.1 части 5 статьи 8 настоящего Федерального закона
То есть обращу внимание: закрытый ключ хранится у УЦ, подпись делает УЦ. Ну, конечно, «по поручению».
Моя ошибка — поверил «на слово» статье. А надо было почитать самому. Ну да лучше поздно, чем никогда.
Вам же в статье написано, что это служба называется «доверенное третье лицо»?
Мне безразлично что назвали вы в статье, я разъяснил употреблённый мною термин. А вот что действительно означает термин «доверенная третья сторона» (цитата непосредственно из законопроекта):
доверенная третья сторона – юридическое лицо, осуществляющее деятельность по проверке электронной подписи в электронных документах в конкретный момент времени в отношении лица, подписавшего электронный документ, для обеспечения доверия при обмене данными и электронными документами
На самом деле это определение не имеет отношения к службе штампов времени. Речь здесь идёт о проверке подписи в определённый момент времени. То есть кто-то (или что-то вроде стороннего сервиса) проверит подпись целиком и скажет, была ли она корректная в какой-то конкретный момент времени. Служба штампов времени же просто подписывает хэш сообщения, без какой-то проверки подписи.
У вас поверхность неполная
Откуда вам известно полная она у меня или нет? Я вот считаю что она, поверхность эта, у меня достаточно упитанная, так сказать :)
Или вы считаете, что вам лучше знать?
А приведите-ка цитату из законопроекта, где хоть что-то говориться о ФНС. Может я что-то пропустил.
… но при этом искренне считая себя энтузиастом в этой области, который разбирается в вопросе лучше, чем 95% (а то и 99%) населения...
Так случилось, что я вхожу в этот 1% населения, который разбирается в этом вопросе лучше вас.
Под «электронным нотариусом» я понимал службу штампов времени. Материальная ответственность может возникнуть только если будет принят соответствующий закон. Пока такового нет. Да и в случае со службой штампов времени создать некорректный штамп достаточно сложно, в отличие от работы с обычным нотариусом. И регулируется всё это соответствующими политиками безопасности.
По поводу ФНС. Идея выдачи сертификатов юрлицам прямо при получении документов лежит на поверхности и обсуждается уже много лет. Однако существует перечень «доводов против». Ведение УЦ явно выходит за рамки компетенции этой службы. Так что УЦ будет вести кто-то другой. А вот что достанется ФНС так это упрощённые функции RA (Registration Authority). Причём выполнять эти функции ФНС будет, по сути, бесплатно, просто в нагрузку к существующим процессам. Конечно, выдачу сертификатов заложат в соответствующие сборы, вот только, как мне кажется, ФНС будет перепадать основной геморрой от общения с клиентами и очень мало денежек. Так что ещё раз — ФНС, как мне кажется, будет сильно сопротивляться.
У меня есть подозрения, что описываемая здесь система достаточно ущербна. Но чтобы это подтвердить или опровергнуть мне нужны дополнительные сведения.
Конкретные числа действительно большие. Однако если уж предлагаете какую-то "инновацию" рекомендую предусматривать возможность разрастания базы. Это всегда полезно. И где же обещанный документ, объясняющий мне остальные мои вопросы?
Вы про PKIJS в курсе? Или просто было интересно велосипед пописать?
Круто, спасибо!
Насчёт проверки «средствами сертифицированными ФСБ». Скорее всего здесь идёт речь о создании некой отдельной структуры, которая будет дополнительно собирать деньги с пользователей. Также это может быть ещё одним шагом к тотальному контролю за использованием криптографии: представим, что ключи хранятся только в УЦ, подписи делает только сервис УЦ, подписи проверяет только «доверенная третья сторона». Так что подразумевается только один дополнительный шаг — запрет использования локальных программ создания/проверки подписи. И, кстати, «средства сертифицированные ФСБ» не обязательно должны обладать расширенными средствами проверки подписей. Сертификация предполагает лишь проверку корректности встраивания криптографических средств, не более того.
У меня уже голова кругом от ваших ответов. Вы что имели в виду, когда писали про OCSP? Вас в последней цитате смущает факт, что кроме проверки подписей доверенная сторона ещё и действительность сертификата проверяет или что? Как это «момент времени описать в терминах метки доверенного времени»?
УЦ отзывает существующий сертификат и выдаёт новый, с хранением закрытого ключа в УЦ. Вот и весь процесс. И, кстати, внутри УЦ тоже используется HSM, который тоже типа «с неизвлекаемыми ключами».
Он очень даже существующий. А чего-то «давить» сами начали: никто ничего не знает, только в теории, я лучше 99% населения. П**здец профи.
Собственно вся эта «дискуссия» вышла из-за того, что вы как-то связали понятия «доверенная третья сторона» и «служба штампов времени». Я вам показал прямо определение, прямо из законопроекта, на что вы придумали какую-то ерунду и пытаетесь что-то доказывать. Даже в дополнении к пункту 18.1, на который вы что-то часто напираете, ничего нет про выполнение доверенной третьей стороной функции служба штампов времени. Там только про проверку подписи. Почитайте.
Прекратите делать какие-то предположения по поводу что мне известно, а что нет. Я сам писал такие сервисы несколько лет назад, и они даже работали :)
Чего? Вы считаете, что надо сертификат на данный момент проверять и всё? Скажу вам, что процесс проверки подписи, особенно «advanced» (CAdES) включает в себя очень доскональную проверку сертификата, однако это достаточно маленький этап всей проверки. OCSP вообще тут упоминать «ни к селу, ни к городу», это просто сервис, его ответ просто встраивается в подпись, если нужно.
Почитайте дополнения к пункту 18.1 в законопроекте, там написано. Вводят сущность, которой поручаются функции доверенной проверки подписей и выдачи квитанций о данной проверке. Ничего более.
Товарищ «энтузиаст», OCSP — это сервис проверки «не отозванности» сертификата в данный момент. Он не проверяет никакой подписи.
Вы бы хоть посмотрели, кто я такой, прежде чем это всё писать. Я программист с 16-ти летним стажем в информационной безопасности. Я ведь не «энтузиаст», я этим зарабатываю.
То есть обращу внимание: закрытый ключ хранится у УЦ, подпись делает УЦ. Ну, конечно, «по поручению».
Мне безразлично что назвали вы в статье, я разъяснил употреблённый мною термин. А вот что действительно означает термин «доверенная третья сторона» (цитата непосредственно из законопроекта):
На самом деле это определение не имеет отношения к службе штампов времени. Речь здесь идёт о проверке подписи в определённый момент времени. То есть кто-то (или что-то вроде стороннего сервиса) проверит подпись целиком и скажет, была ли она корректная в какой-то конкретный момент времени. Служба штампов времени же просто подписывает хэш сообщения, без какой-то проверки подписи.
Откуда вам известно полная она у меня или нет? Я вот считаю что она, поверхность эта, у меня достаточно упитанная, так сказать :)
А приведите-ка цитату из законопроекта, где хоть что-то говориться о ФНС. Может я что-то пропустил.
Так случилось, что я вхожу в этот 1% населения, который разбирается в этом вопросе лучше вас.
По поводу ФНС. Идея выдачи сертификатов юрлицам прямо при получении документов лежит на поверхности и обсуждается уже много лет. Однако существует перечень «доводов против». Ведение УЦ явно выходит за рамки компетенции этой службы. Так что УЦ будет вести кто-то другой. А вот что достанется ФНС так это упрощённые функции RA (Registration Authority). Причём выполнять эти функции ФНС будет, по сути, бесплатно, просто в нагрузку к существующим процессам. Конечно, выдачу сертификатов заложат в соответствующие сборы, вот только, как мне кажется, ФНС будет перепадать основной геморрой от общения с клиентами и очень мало денежек. Так что ещё раз — ФНС, как мне кажется, будет сильно сопротивляться.