Security model
The design goal is simple to state: the add-in proves you’re licensed and proves your model’s claims without depending on a server you have to trust at runtime. Verification happens offline against public keys, the matching private keys never touch your machine or the website, and your data stays where you put it.
Offline verification against public keys
Public-key cryptography splits a key into a private half (which signs) and a public half (which verifies). ModelxcelPro ships only the public half: the add-in carries an embedded public keyset and uses it to verify a license’s signature locally. Because verification needs only the public key, it works with no network connection — and because the add-in has no private key, possessing the add-in gives you no power to mint or alter a license.
A current (v3) license verifies as ES256 (P-256 ECDSA) against that embedded keyset; a legacy v2 license verifies against the v2 public key. The verifier is strict: it rejects an unknown or revoked signing key, a bad signature, a non-canonical payload (one whose bytes don’t re-serialize identically), a wrong machine code, or an expired license. See Activation & machine binding for the per-startup sequence.
Where signing keys live — and where they don’t
This is the heart of the model:
- The add-in holds only public keys. It can verify, never sign.
- The website holds no signing key at all. When the website needs a license issued, it calls the C# licensing portal over an authenticated, HTTPS-only contract; the portal signs and returns the finished license. (See Admin & signing.)
- Production signing happens inside Azure Key Vault. The portal asks Key Vault to sign a digest; the private key never leaves the vault and never exists in the portal’s process memory. A separate local/dev signer exists for development and staging only and is hard-blocked from running in production.
Honest status: the embedded key is a development key
The production Key Vault signing path is implemented, but a production signing key is not yet provisioned for the private beta — the public key embedded in the current build is a development key (its key id contains dev), and the release-readiness check is designed to fail until a real production key is embedded. Treat current-build licenses as beta artifacts. This is provisioning status, not a flaw in the verification design.
Your data stays on your machine
Nothing about using the add-in requires uploading your model. Everything ModelxcelPro produces lives on your own disk, in or beside the workbook:
The full catalog of files, where each lives, and what’s safe to share is on the File types reference.
What leaves your machine
Be precise about this. The add-in makes no routine, automatic network call — no background telemetry and no license “phone home” in the current build. The only times Excel reaches the network are actions you take:
- Opening “Full documentation” launches your default browser to a docs URL. The in-Excel Help pane itself is fully offline.
- Binding a URL or API source in the Proof system fetches the source you explicitly point it at so it can hash a snapshot — a deliberate, user-initiated action, not background telemetry.
A license freshness/revocation endpoint exists on the website (/api/license/validate), designed for the add-in to call rarely, cached, and fail-open. That online check is a planned layer, not yet wired into the add-in; when it lands it will send only a licenseId and receive booleans back (no customer data, no model data). See the Activation page.
No background telemetry, no LLM, no cloud sign-in
The in-product Help & Commands pane is a deterministic, offline search index — no external calls and no language model. Activation requires no Azure or cloud sign-in from Excel, and the add-in does not phone home with your model. In the current build there is no routine license network call at all — verification is fully offline.
Cryptography, by feature
Different parts of ModelxcelPro use different primitives for different jobs. Knowing which is which keeps conversations with auditors precise — for example, “signed” in the Proof group means a reviewer attestation in the ledger, not an Authenticode signature.
| Where | Primitive | What it protects |
|---|---|---|
| License files (v3) | ECDSA ES256 (P-256) | Authenticity of the license; signed by the portal, verified offline by the add-in. |
| Machine code | SHA-256 hash | A one-way fingerprint of stable machine signals — never the raw identifiers. |
| Proof ledger | SHA-256 hash chain | Tamper-evidence: any edit or reorder of records is detectable. |
| Certificate | SHA-256 self-hash | Integrity of an exported snapshot — but not a public-key signature, so it’s not externally verifiable. |
| Replay Proof | Ed25519 signature | An independently verifiable certificate of an output movement (.mxreplay.signed). |
These are independent systems with independent keys: licensing’s ES256 keys, the proof ledger’s hashing, and Replay Proof’s local Ed25519 keypair have nothing to do with one another.
Installer signing (beta reality)
The installer is not yet Authenticode code-signed
During the private beta the installer (ModelxcelPro.exe and its MSI) is not code-signed — the signing pipeline exists but is inert until a code-signing certificate is provisioned. Expect a Windows SmartScreen “unknown publisher” prompt; choose More info → Run anyway. A signed build ships before general availability. See Install.
Where to go next