Origin-ізоляція: чому віджети не можна хостити в себе
Віджети завантажуються тільки з dstucrypt.io — окремого origin, що не
належить вашій сторінці. Це не обмеження, а основа моделі безпеки:
Same-Origin Policy браузера зводить між вашим сайтом і віджетом глуху
стіну, тож жоден JS вашої сторінки не може зазирнути всередину віджета — ні
файл ключа, ні пароль недосяжні, навіть якщо ваш сайт скомпрометовано
через XSS.
Доступу до ключа не має ніхто, крім самого користувача: уся робота з ключем відбувається локально в його браузері, всередині ізольованого iframe, і на сервери DSTUcrypt ключ чи пароль не передаються ніколи. Тобто ключа не бачите ні ви, ні ми — і це гарантія самого браузера (ізоляція origin-ів), а не чиясь обіцянка.
Якби файли віджетів лежали на вашому сервері, межа origin-ів зникла б — і будь-який XSS на вашій сторінці читав би ключі користувачів.
Що перетинає межу iframe
Тільки дані операції (які у вас і так є) і результат. Ніколи — байти
ключа чи пароль. Обмін відбувається всередині браузера через postMessage:
байти передаються напряму (ArrayBuffer), без проміжних base64-рядків і без
жодних мережевих запитів.
ваша сторінка → iframe : дані для підпису + параметри
iframe → ваша сторінка : готовий підпис (байти)
Криптографія: WebAssembly, а не саморобний JS
Криптоарифметика виконується перевіреною нативною C++-бібліотекою, скомпільованою у WebAssembly:
- константний час операцій — захист від timing-атак;
- коректний одноразовий
kпри кожному підписі — захист від відновлення приватного ключа аналізом готових підписів (класична слабкість чисто-JS реалізацій ДСТУ); - ентропія — з CSPRNG браузера.
Бонус продуктивності: WASM виконується з майже нативною швидкістю — на відміну від чисто-JS криптографії, підпис і гешування великих файлів працюють швидко навіть на старих і слабких пристроях користувачів.
Вхід за КЕП: перевірка на сервері, не в браузері
Результату перевірки підпису, отриманому в браузері клієнта, довіряти не можна — браузер контролює користувач. Тому для авторизації ми перевіряємо підпис на нашому сервері нативним криптоядром, а одноразовий challenge унеможливлює повторне використання. Деталі — у розділі Вхід за КЕП.
Це саме правило стосується будь-яких критичних рішень за підписом: приймаєте документ чи платіж — перевіряйте підпис на бекенді, а не вірте вердикту з браузера.
Ліцензійний захист і плашки
- Доступ віджетів до домену контролюється на нашому сервері заголовком
Content-Security-Policy: frame-ancestors: браузер відмовляється рендерити віджет на неактивованому домені. Підробити чужий домен неможливо — origin батьківської сторінки засвідчує браузер. - Новий домен автоматично отримує 7 днів випробувального періоду (плашка з залишком днів у віджеті).
localhost— завжди вільний, із плашкою «режим розробника».- Після завершення оплати доступ зупиняється автоматично.
Мітки часу і квоти
TSP-запити йдуть через наш вбудований проксі з автоматичними фолбеками між серверами АЦСК. У базовій підписці — 1 000 міток часу на добу на домен; рахуються лише успішно видані мітки.