NCALayer - начало разработки

Добрый день!
Разработка ведется на Delphi и нет возможности использовать Kalkan на MacOS и Linux.
Поэтому решили использовать NCAlayer. Однако не получается по Вебсокету соединиться с ним.
Вопросы:

  1. Для подключения к NCAlayer требуется какое-то разрешение?
    Нигде не нашел инструкцию по командам соединения с NCALayer.
  2. Для чего добавляются в список модулей NCAlayer различные компании? Я так понял, если в список добавлена компания, то она может в фоновом режиме (без отображения окна NCALayer), вызывать функции этой прослойки? И если допустим моей компании в списке модулей нет, то окно будет всегда отображаться?

С Уважением,
Рустам

Здравствуйте. Под Kalkan вы имеете в виду KalkanCryptCOM? Если да, то у них с NCALayer разные предназначения. NCALayer предназначен для работы на клиентской стороне.

Для подключеия к NCALayer не требуются разрешения. Пример использования NCALayer есть в SDK.

Модули различных ИС добавляются в NCALayer, потому что у каждой ИС свои требования и им нужны методы специфичные для их систем. Это не связано с отображением окон.

Добрый день,

Вы можете попробовать интерактивно отправлять команды NCALayer на странице документации KAZTOKEN mobile: https://kaztoken.kz/mobile-docs/

KAZTOKEN mobile повторяет функционал NCALayer, так что команды совпадают.

Спасибо ребята за оперативную информацию, немного стал разбираться
(вот бы мне так хорошо помогали в ESF, там сущие лентяи и беспредел).

Еще парочка вопросов коллеги:

  1. Я исправил под себя JS и он теперь все делает сам в плане подписи XML.
    Но я так понял верификации XML не существует в NCALayer ?
  2. Если верификацию NCALayer не делает, то я вынужден использовать другие модули типа KalkanCrypto, JAR и т.п.?
  3. Если верификацию NCALayer не делает, то почему ее не делают? И я так понял не собираются?
  4. Я правильно понимаю NCALayer при подписи XML сам за меня проверит сроки ключа и отозван ли он ?

С Уважением,
Рустам

Рустам, на сколько мне известно, NCALayer не проверяет подписей.

По хорошему подписи вам нужно проверять на стороне сервера, так же не забывайте о том, что вашей реализации необходимо соответствовать Приказу о правилах проверки подписи (http://adilet.zan.kz/rus/docs/V1500012864) иначе ни о какой юридической значимости речи идти не может.

Упростить задачу можно воспользовавшись готовым решением для проверки подписей - сервисом SIGEX:

Ну у меня так в планах:

  1. Подпись JS : “module”: “kz.gov.pki.knca.commonUtils”,“method”: “signXml” (Вроде нет шансов прочитать файл или пароль)
  2. Верификация JAR: JAR библиотека. (Тут тем более только открытый ключ)

Разве при этом есть какие-то варианты нарушить приказ?

  1. Да, в основном модуле NCALayer нет верификации, так как верификация выполнятеся на стороне сервера.
  2. Да, для верификации вам нужно использоват СКЗИ Kalkan предоавленный на Java и C в нашем SDK. Примеры верификации также есть в SDK.
  3. Верификация в основной модуль NCALayer не добавляется, так как она выполняется на стороне сервера. Некоторые системы написали свои модули NCALayer, в которых есть все необходимые для них методы. Инструкция по созданию собственного модуля описана в SDK.
  4. Нет, NCALayer просто подпишет данные уазанным вами ключом. Верификацию нужно будет выполнять отдельно. Однако при выборе ключа отображается примечание о сроке. Вы можете проверить это на примере в SDK в папке “SDK 2.0\NCALayer\commonbundle_sample”

Передача открытого ключа не нарушает правила проверки, но вам все же стоит с ними ознакимться.

Неееееееет, NCALayer не проверяет отозванность сертификатов? Это же горе масштабное, как так-то? прошло 20 лет и такое не реализовали? Все весь образ жизни придеться менять, неужели придеться вернуться в 17 век и проверять отозванность через открытый ключ отдельными запросами из JAR (автор плачет…). Кто-нить скажите что это все неправда, я не хочу верить в это, не-хо-чу.

1 Симпатия

Не совсем понятно при чем тут “20 лет”. Основная функция NCALayer - подписать данные указанным ключом. Проверка выполняется на стороне сервера.
NCALayer исползуется в различных системах, в том числе тех, где у пользователей нет доступа к интернету. Соответственно они не смогут подключиться к OCSP сервису или скачать CRL файл для проверки на отозванность.

Хотелось бы коробочное решение всем понятное, которое бы позволило комфортно работать с ЭЦП на MacOS, Linux и конечно Android и IOS.
“Коробка” должна уметь:

  1. Легко устанавливаться на все платформы ОС(инструкци, обновления, техподдержка).
  2. Прочитать инфу ключа(также я бы хотел это видеть в п.3 и 4, х509 не вариант).
  3. Подписать.
  4. Верифицировать.
  5. Проверить сроки ЭЦП.
  6. Проверить отозванность сертификата.
  7. Не позволять напрямую прикасаться к файлам ЭЦП и паролям.
    NCALayer зарекомендовал себя отлично по многим пунктам: 1,2,3 и самое важное - 7 (на хабре п.7 критикуют почемуто).
    Однако пункты 4, 5, и 6 почему то не реализованы, т.е. 40% того что должно было быть, есть куда развиваться.
    Тут мне сообщили, что некоторые сами разработали свои “NCALayer”(сокеты), но вот как раз
    им и придеться доказывать, что они не нарушают приказ/закон, не копируют себе ключи, и не подписывают, что попало.
    Вы этом плане NCALayer куда проще, ваш продукт публичный, все претензии к владельцу ).

Моя критика не негативная, а призыв к развитию. Чтобы не уподоблялись бездарям из ESF.
Я знаю, что п.4 обязателен на сервере, пусть это будет 2х факт проверкой, потому что
вы возможно не видели ярость человека получившего отказ в верификации спустя 1 час, причин полно.
Согласитесь куда более приятнее получить отказ сразу и снова подписать уже корректнее, не теряя ценного времени.
Давайте ребята я в вас верю, п.6 мегаважный, и уверен вы сможете сделать это, ведь скази на клиенте на JAR.

1 Симпатия

Это не связано с развитием. Во-первых, все проверки должны производиться на стороне сервера так как вы не знаете, что именно вам прислал пользователь или злоумышленник. Во-вторых нам пришлось убрать некоторые проверки так как некоторые системы надеясь на NCALayer не проводили проверки на своей стороне. Ну и в третьих, у каждой системы свои требования. Некоторые могут требовать метку времени, а для некоторых это лишнее. Некоторые пользователи работают без доступа к интернету и следоавтельно проверки на отозванность по сервису OCSP и использование сервиса метки времени для них невозможно. Поэтому основной модуль NCALayer (Common Bundle) максимально прост и выполняет только самые необходимые функции. Если у системы специфичные требования, то они могут добавить свой модуль в список модулей NCALayer.

как это незнаю? для верификации я должен передать свой XML.

А для чего приказ, которым всех пугают? Так и знал филькина грамота.
Если человек использует печку в автомобиле для разогрефа донеров, это незначит что другим надо печку запрещать. Где логика?

уверен это низкая доля, непонятно где это нужно, там где почтовые обмены? тогда им точно хотя бы предварительная верификация нужна.
срок ключа по открытому ключу можно прочитать на край. И снова возвращаясь к безалтернативности, списком функции вы же не ограничены, в скази у вас всего полно, это никак не утяжелит программу.

Пользователь передает подпись, но он может передать все что угодно, поэтому и нужна проверка на стороне сервера.

О чем речь? Вы даже не прочитали эти правила и закон об электронной подписи.

Доля тут не важна. Суть в том, что есть такие системы и требуется чтобы NCALayer мог работать в таких условиях Каким образом вы собираетесь проверять статус отзыва по OCSP без доступа в интернет?

Как я уже сказал, проверки не добавляются, потому что они должны выполнятся на стороне сервера, а не из-за того что они “утяжелят” программу.

1 Симпатия