Comments 34
А что помешает недобросовестному лицу сделать QR-код со ссылкой на свой сайт, где будет написано «Всё честное и настоящее, мамой клянусь, вах!»? Без доверенных и всем известных центров (хотя бы тот же Ростехнадзор) полезный эффект будет небольшой. Разве что лаборатория заведет себе сайт. Но и этот факт (и этот сайт) должен быть широко известен.
Именно для этого я и придумал свой сервис, который может стать тем ресурсом, которому можно доверять.
А, действительно, если мошенник захочет — он может измахриться и сделать копию моего сайта, на котором будет подтверждать подлинность документов. Тогда в QR-код я буду добавлять название веб-сайта.
Хотя, конечно, в этом есть истина, лучше сервис раскрутить и продать Ростехнадзору.
А, действительно, если мошенник захочет — он может измахриться и сделать копию моего сайта, на котором будет подтверждать подлинность документов. Тогда в QR-код я буду добавлять название веб-сайта.
Хотя, конечно, в этом есть истина, лучше сервис раскрутить и продать Ростехнадзору.
У китайской налоговой документы работают примерно так. В левой верхней части есть здоровенный QR-код, который ведёт на сайт в домене *.gov, где лежит электронная версия этого же самого документа. И на сайте налоговой можно точно так же вбить номер документа и проверить его содержимое.
В целом, ничто не мешает написать приложение, которое будет игнорировать ссылки за пределами домена в зоне *.gov.
В целом, ничто не мешает написать приложение, которое будет игнорировать ссылки за пределами домена в зоне *.gov.
Почему без соли шифруете?
Спасибо за комментарий. В тонкостях работы алгоритмов шифрования пока не разобрался.
Вы полагаете, что недостаточно иметь 128-битный ключ?
Вы полагаете, что недостаточно иметь 128-битный ключ?
Ключ это несолько другое, хотя если нет технических ограничений можно взять 256. У используемой библиотеки github.com/ricmoo/aes-js прямо в ридми есть пример шифрования с использованием initialization vector, например CBC вариант.
В тонкостях работы алгоритмов шифрования пока не разобрался.
Вы опасно некомпетентны в криптографии
Там не про AES, но всё равно. Если вы не в курсе про соль (и про CBC), то вы явно опасно некомпетентны
Некомпетентен, не спорю. Спасибо за ссылку!
Прочитал статью. В целом ощущение, что товарищ защищает свою делянку профессионала и правильно делает.
Если рассуждать, как автор статьи, то можно дойти до того, что нельзя готовить дома салат по рецепту, потому что только профессионал знает секрет, из какой стали должен быть нож, которым ты режешь капусту.
Но в этом и преимущества современных открытых технологий, что не будучи компетентным в каждом из компонетнов системы, энтузиаст может собрать работоспособное, но не идеальное приложение. Вряд ли мой ключ попытаются ломать теми методами, которые описаны в статье. Я не делаю новую соцсеть, хранилище персональной и финансовой информации.
Когда я выбирал алгоритм для шифрования, залез почитал про AES (не то как он работает — мне это было не важно), а то что он рекомендован правительством США для документов уровня SECRET с ключом 128.
Я даже исхитрился и сделал так, что сам ключ в базе данных не хранится. Украсть его не получится.
Ниже товарищи указали, что следовало бы воспользоваться асимметричным шифрованием, возможно это разумно. Но вместе с тем, мое решение работоспособно и пока я не увидел принципиального изъяна кроме самого сомнения в том, что сервис действительно предоставляется не надежным с административной точки зрения. Тут уж надо, видимо переходить на blockchain, но это будет уже выходить за пределы любительского pet-проекта.
Если рассуждать, как автор статьи, то можно дойти до того, что нельзя готовить дома салат по рецепту, потому что только профессионал знает секрет, из какой стали должен быть нож, которым ты режешь капусту.
Но в этом и преимущества современных открытых технологий, что не будучи компетентным в каждом из компонетнов системы, энтузиаст может собрать работоспособное, но не идеальное приложение. Вряд ли мой ключ попытаются ломать теми методами, которые описаны в статье. Я не делаю новую соцсеть, хранилище персональной и финансовой информации.
Когда я выбирал алгоритм для шифрования, залез почитал про AES (не то как он работает — мне это было не важно), а то что он рекомендован правительством США для документов уровня SECRET с ключом 128.
Я даже исхитрился и сделал так, что сам ключ в базе данных не хранится. Украсть его не получится.
Ниже товарищи указали, что следовало бы воспользоваться асимметричным шифрованием, возможно это разумно. Но вместе с тем, мое решение работоспособно и пока я не увидел принципиального изъяна кроме самого сомнения в том, что сервис действительно предоставляется не надежным с административной точки зрения. Тут уж надо, видимо переходить на blockchain, но это будет уже выходить за пределы любительского pet-проекта.
Да даже если с солью и перцем шифровать — общая схема неверна. Соль нужна для хэша, а не симметричного алгоритма.
Имелось ввиду использование рандомного initialization vector. Об общей схеме речи не было.
Ок, но тогда ошибка в терминологии. Initialization Vector — это не соль. IV обязан храниться в секрете (UPD: на самом деле нет, ошибся), в то время как соль хэша можно хранить в открытом виде.
Каюсь что статью не читал, только код посмотрел и сразу комментировать, как обычно.
IV обязан храниться в секрете, в то время как соль хэша можно хранить в открытом виде, это не секрет.Мне казалось что IV не должен повторятся при использовании того же самого ключа (рандом), а хранение в секрете желательно, также как и для key derivation хешей, но не обязательно.
Вам нужно почитать про криптографию с открытым/закрытым ключём.
Создаём qr код с ОТКРЫТЫМ текстом и его подписью закрытым ключём. Для проверки нужен всего лишь открытый ключ, ну и открытая база открытых ключей организаций, которым вы доверяете.
Спасибо, я понял!
А можно ли добавить открытый ключ в ту же зашифрованую гиперссылку?
Тогда она будет выглядеть как ОТКРЫТЫЙ_ТЕКСТ&ПОДПИСЬ&ОТКРЫТЫЙ_КЛЮЧ и мой сервис просто верифицирует подпись.
К счастью я сразу предусмотрел в формируемой ссылке поле version. В версии 2.0 учту.
А можно ли добавить открытый ключ в ту же зашифрованую гиперссылку?
Тогда она будет выглядеть как ОТКРЫТЫЙ_ТЕКСТ&ПОДПИСЬ&ОТКРЫТЫЙ_КЛЮЧ и мой сервис просто верифицирует подпись.
К счастью я сразу предусмотрел в формируемой ссылке поле version. В версии 2.0 учту.
Вы правы, чтобы проверить подпись нужно знать кто подписал. Но все равно вам нужна отдельно база тех, кому вы доверяете. Иначе плохая организация может сгенерировать открытый ключ и валидную подпись, но так как этого сгенерировано ключа нет в вашей базе, то он фейковый.
Об этом можно почитать — инфраструктура открытых ключей PKI.
Спасибо, почитал.
Теперь мне стало ясно что такое по сути ЭЦП.
Получается что все-равно нужен кто-то кому все доверяют. Тогда придется брать на себя роль УЦ, а это уже регулируется законодательством.
Но в то же время я думаю вот о чем — о практике применения. Если все сделать по принципу ЭЦП, то представитель лаборатории может продать/передать/потерять закрытый ключ и его работодатель об этом не узнает.
Представьте себе к, примеру, организацию которая выписывает медицинские справки. Ясное дело, что у того, кто имеет доступ к ключу есть искушение начать работать «налево».
Да, он точно также может и продать/передать/потерять доступ к личному кабинету на моем сайте, где хранится ключ и тогда левые организации или он сам смогут подписывать фейковые документы.
Для этого у меня ведется учет сгенерированных документов. Пока просто по количеству. Соответственно, если количество защищенных документов не будет сходиться с количеством официально выпущенных, значит что-то пошло не так и об этом будет известно при ежемесячном отчете.
Теперь мне стало ясно что такое по сути ЭЦП.
Получается что все-равно нужен кто-то кому все доверяют. Тогда придется брать на себя роль УЦ, а это уже регулируется законодательством.
Но в то же время я думаю вот о чем — о практике применения. Если все сделать по принципу ЭЦП, то представитель лаборатории может продать/передать/потерять закрытый ключ и его работодатель об этом не узнает.
Представьте себе к, примеру, организацию которая выписывает медицинские справки. Ясное дело, что у того, кто имеет доступ к ключу есть искушение начать работать «налево».
Да, он точно также может и продать/передать/потерять доступ к личному кабинету на моем сайте, где хранится ключ и тогда левые организации или он сам смогут подписывать фейковые документы.
Для этого у меня ведется учет сгенерированных документов. Пока просто по количеству. Соответственно, если количество защищенных документов не будет сходиться с количеством официально выпущенных, значит что-то пошло не так и об этом будет известно при ежемесячном отчете.
Отвечу сам себе )
Один из заказчиков как раз посетовал, что сотрудники левачат и делают диагностичиеские карты не на рабочем месте, соответвенно он им не доверяет.
Я добавил возможность привязать аккаунт к конкретному устройству.
Ну что же - полностью ручная работа с моей стороны, но для такого маленького проекта это выполнить не сложно.
1. Вы в корне неправильно применяете криптографические примитивы. Вам не нужно шифровать информацию симметричным алгоритмом (AES128), т.е. скрывать содержимое от третьих лиц, ведь результаты дефектоскопии прописаны в бланке в открытом виде и ни для кого секрета не представляют. Вам необходимо именно аутентифицировать содержимое бланка, т.е. гарантировать обнаружение подделки. Для этого применяются совсем другие средства.
2.
2.
К аккаунту пользователя привязывается уникальный закрытый ключ шифрования.Если я правильно понял, то вы на сервере храните симметричные ключи от всех аккаунтов, что очень плохо, т.к. их могут украсть. Таким образом я, как пользователь сервиса никогда не смогу узнать, что ключ был продан, а все мои новые бланки с какого-то момента подделаны. Но это уже следствие первой проблемы.
Спасибо, за комментарий. Я рассчитывал что профессиональное сообщество укажет мне на мои ошибки.
К счастью я сразу предусмотрел в формируемой ссылке поле version. В версии 2.0 учту что подход должен быть с открытым/закрытым ключом.
Кстати, я не храню сам ключ в базе данных. Для передачи в алгоритм шифрования то что хранится в базе данных определенным образом дополнительно преобразовывается. То есть надо не только украсть сам «ключ» но и найти тот код, который трансформирует его.
К счастью я сразу предусмотрел в формируемой ссылке поле version. В версии 2.0 учту что подход должен быть с открытым/закрытым ключом.
Кстати, я не храню сам ключ в базе данных. Для передачи в алгоритм шифрования то что хранится в базе данных определенным образом дополнительно преобразовывается. То есть надо не только украсть сам «ключ» но и найти тот код, который трансформирует его.
Для передачи в алгоритм шифрования то что хранится в базе данных определенным образом дополнительно преобразовывается. То есть надо не только украсть сам «ключ» но и найти тот код, который трансформирует его.
Это называется «Security through obscurity» — безопасность достигается путем секретного алгоритма. В современно мире считается, что на подобных принципах стоить безопасность недопустимо. Весь анализ возможных атак всегда строится в предположении, что все алгоритмы есть в распоряжении взломщика. Причем, не только обфусцированный код, а полная документация с указанием того, что, зачем и почему именно так там делается.
Мне кажется, что у злоумышленников есть все возможности подобрать симметричный ключ перебором.
UFO just landed and posted this here
Можно, и это вполне реальное решение для той организации, которая выдает документы. Но для этого нужно каждому городить свое собственное решение, делать портал на который будут скидываться документы из ряда лабораторий, работающих на местах, короче некое инфрастуктурное IT решение, до которого у большинства просто руки не доходят.
А моя идея состоит в том, чтобы предоставить такой сервис любой компании — маленькой и большой, но при этом сами данные не хранятся у меня, хранятся только ключи к расшифровке.
А моя идея состоит в том, чтобы предоставить такой сервис любой компании — маленькой и большой, но при этом сами данные не хранятся у меня, хранятся только ключи к расшифровке.
Самое простое решение — выкладывать по ссылке site.com/22345200-abe8-4f60-90c8-0d43c5f6c0f6/10465677-c121-99j0-1111-22187a169871/act.pdf
Саму ссылку зашивайте в QR-код. Защита основана на сложности перебора длинных путей и отсутствия единого публичного списка всех ссылок.
Выложить файл на сайте — что может быть проще.
Вы жалуетесь что для этого надо городить своё решение, но при этом, вас почему-то устраивает необходимость создания своего решения в виде мобильного приложения.
Саму ссылку зашивайте в QR-код. Защита основана на сложности перебора длинных путей и отсутствия единого публичного списка всех ссылок.
Выложить файл на сайте — что может быть проще.
Вы жалуетесь что для этого надо городить своё решение, но при этом, вас почему-то устраивает необходимость создания своего решения в виде мобильного приложения.
Конечно, проще всего было бы забивать номер документа на сайте (или кодировать ссылку с этим номером), и сайт бы показывал какие-то ключевые данные о документе. Но, если информация секретная (даже не представляю причин, почему она может быть секретной, но это наше общее тяжелое наследие), то тогда только и остается генерировать гигантские QR-картинки. Можно попробовать переводить в собственный алфавит, который из 5-6 бит, а значит немного ужать количество информации. Или даже даже сделать свою вариацию хаффмана с известной таблицей кодирования/декодирования — можно будет еще немного ужать.
Sign up to leave a comment.
Как я решил защищать документы от подделки и «изобрел» электронную цифровую подпись