- Confidentiality of FPGA device-data IP (.en files) at rest on end-user machines and in transit.
- Integrity / authenticity: detect any tampering with ciphertext or container metadata.
- Per-customer key isolation: a leak of one customer's key does not compromise others' encrypted assets.
- No long-lived plaintext on disk for IP files consumed by Aurora2; decryption happens in memory and the cache is wiped on process exit.
- Side-channel resistance against a co-located adversary — qlcrypt uses Crypto++'s production AES, which has constant-time C++ paths and may use AES-NI/ARMv8-AES when available. We do not make guarantees about cache-timing on hostile multi-tenant hardware.
- Hardware key wrapping (TPM/SE/HSM) — out of scope for v1.x; planned post-1.0.
- Streaming encryption for files larger than host RAM — not
supported in current API; entire plaintext is held in
std::string. - Forward secrecy — one symmetric key per database; rotation must
be performed explicitly via
qlcrypt rotate.
The adversary is assumed to be able to:
| Capability | Mitigation |
|---|---|
Read the encrypted .en files on disk |
AES-256-GCM with random per-file 96-bit nonce |
Modify any byte of the .en file |
GCM 128-bit authentication tag covers ciphertext + 27-byte header (as AAD) |
| Truncate or extend the file | Header plaintext_len is AAD-bound; output length verified after auth succeeds |
| Reorder, swap, or splice ciphertext blocks within or across files | GCM tag invalidates any modified ciphertext; nonce binding prevents cross-file splice |
| Substitute one customer's key for another | KeyDB records optional customer-id; fingerprint (8-byte SHA-256 prefix) supports leak attribution |
| Capture a single file with known plaintext | AES-GCM is IND-CPA; one known plaintext does not yield the key |
| Reuse a captured nonce + ciphertext under a different key | Authentication fails (key-bound MAC) |
The adversary is not assumed to:
- Run code in the same process address space as qlcrypt.
- Modify the qlcrypt binary or the
_Supp.dbkey database. - Mount a side-channel attack against the AES-NI/ARMv8-AES core.
| Primitive | Library | Notes |
|---|---|---|
| AES-256 in GCM mode | Crypto++ | NIST SP 800-38D; 96-bit IV, 128-bit tag |
| Random nonce + key generation | Crypto++ AutoSeededRandomPool |
sources from /dev/urandom, getrandom(), or platform CSPRNG |
| Key fingerprint | Crypto++ SHA-256 | first 8 bytes of SHA-256(key) |
| Key serialization | cereal portable binary | wrapped in QLKDBv02 magic + schema version |
- All key bytes live in Crypto++'s
SecByteBlock, which guarantees a secure-wiping deallocator. - Plaintext caches in
Processorarestd::strings wiped viaCryptoPP::SecureWipeBufferbefore destruction. - On Linux,
mlock+madvise(MADV_DONTDUMP)is attempted on cached buffers; on Windows,VirtualLock. Failures are silent (best-effort) because unprivileged processes routinely cannot lock pages. prctl(PR_SET_DUMPABLE, 0)andsetrlimit(RLIMIT_CORE, 0)are attempted atProcessorconstruction.
Legacy v1 files used AES-128-GCM with a single shared IV stored in
_Supp.db. This is cryptographically weak (nonce reuse with the
same key trivially breaks GCM confidentiality and integrity). qlcrypt
supports v1 in decrypt-only mode for backward compatibility with
older Aurora packages. New encryption always uses v2.
Customers with v1 packages should rotate to v2 keys via
qlcrypt rotate --new-key-db <new> at the earliest opportunity.
Report security issues privately to security@quicklogic.com.
- Please include reproduction steps, affected versions, and a suggested CVSS vector.
- We aim to acknowledge within 3 business days and release a fix within 30 days for critical issues.
- Do not file public GitHub issues for vulnerabilities until a fix has been released.
- 2026-01 (planned, pre-1.0): independent review by an external cryptography consultancy. v1.0.0 will not be tagged until this review is complete and findings are resolved.