Security model

Origin isolation: why you cannot self-host the widgets

The widgets load only from dstucrypt.io — a separate origin that does not belong to your page. This is not a limitation but the foundation of the security model: the browser's Same-Origin Policy builds a solid wall between your site and the widget, so no JS on your page can peek inside the widget — neither the key file nor the password is reachable, even if your site has been compromised via XSS.

No one has access to the key except the user themselves: all work with the key happens locally in their browser, inside the isolated iframe, and the key or password is never sent to DSTUcrypt servers. In other words, neither you nor we ever see the key — and that is guaranteed by the browser itself (origin isolation), not by anyone's promise.

If the widget files lived on your server, the origin boundary would vanish — and any XSS on your page could read your users' keys.

What crosses the iframe boundary

Only the operation data (which you already have) and the result. Never the key bytes or the password. The exchange happens inside the browser via postMessage: bytes are passed directly (ArrayBuffer), with no intermediate base64 strings and no network requests at all.

your page → iframe : data to sign + parameters
iframe → your page : finished signature (bytes)

Cryptography: WebAssembly, not hand-rolled JS

The cryptographic arithmetic is performed by a proven native C++ library compiled to WebAssembly:

• constant-time operations — protection against timing attacks;
• a correct one-time k for every signature — protection against private-key recovery through analysis of produced signatures (a classic weakness of pure-JS DSTU implementations);
• entropy comes from the browser's CSPRNG.

A performance bonus: WASM runs at near-native speed — unlike pure-JS cryptography, signing and hashing large files stay fast even on users' old and low-powered devices.

Sign-in with QES: verification on the server, not in the browser

A signature verification result obtained in the client's browser cannot be trusted — the browser is controlled by the user. That is why, for authorization, we verify the signature on our server with the native crypto core, and a one-time challenge makes replay impossible. Details are in Sign-in with QES.

The same rule applies to any critical decision based on a signature: when you accept a document or a payment — verify the signature on the backend instead of trusting the verdict from the browser.

License enforcement and banners

• Widget access for a domain is controlled on our server by the Content-Security-Policy: frame-ancestors header: the browser refuses to render the widget on a non-activated domain. Spoofing someone else's domain is impossible — the origin of the parent page is attested by the browser.
• A new domain automatically receives a 7-day trial period (a banner in the widget shows the days remaining).
• localhost is always free, with a “developer mode” banner.
• Once the paid period ends, access stops automatically.

Timestamps and quotas

TSP requests go through our built-in proxy with automatic fallbacks between accredited CA servers. The base subscription includes 1,000 timestamps per day per domain; only successfully issued timestamps are counted.