Security you can fabricate.
Software trust has to start somewhere physical. QCore designs that starting point: the QC-SE100 secure element IC family, FPGA-proven roots of trust, licensable HSM IP, and key architectures where the secret is a property of the silicon itself.
- [ FPGA-PROVEN ]
- [ RISC-V RV32IMC ]
- [ FIPS 140-3 L3 DESIGN TARGET ]
- [ DESIGNED FOR INDIAN FABRICATION ]
QC-SE100 SECURE ELEMENT & HARDWARE TRUST ANCHOR IC FAMILY
An indigenous cryptographic secure element and hardware trust anchor IC family — designed in India, for Indian fabrication — anchoring trust in video surveillance, smart metering, and critical IoT infrastructure. The device your camera, meter, or gateway consults before it believes anything, including its own firmware.
Full engine set
- AES, SHA-2 / SHA-3, HMAC
- RSA and ECC P-256 / P-384 — ECDSA and ECDH
- X25519 key agreement
- SP 800-90 TRNG, health-tested
Trust anchor duties
- Secure key storage on-die
- Secure boot support for the host system
- Tamper detection with active response
Built against Indian requirements
- MeitY Essential Requirements for CCTV security
- STQC certification regime
- Smart-metering / AMI security guidelines
- AIS-140 telematics
How the silicon portfolio fits together
- QC-SE100
- The productised IC family — a secure element you design onto a board, built for Indian fabrication and Indian regulatory regimes.
- CoreAnchor™ HRoT
- The FPGA-proven root of trust — running today on physical development silicon, gating live workloads by attestation verdict.
- Q-HSM
- The licensable IP core — a complete hardware security module you integrate into your own ASIC or FPGA design.
Q-HSM RISC-V HARDWARE SECURITY MODULE IP CORE
A hardware security module as an IP core: a secure RISC-V (RV32IMC) controller running machine-mode only, commanding dedicated cryptographic hardware engines. The host CPU asks for operations. It never, under any code path, touches a key.
AES · SHA · ECC
- AES-256 in GCM, XTS, and KW modes
- SHA-2, SHA-3, and SHAKE
- ECC over P-256, P-384, P-521 — ECDSA and ECDH
TRNG · key operations
- SP 800-90 true random number generator, health-tested
- Hardware key generation, wrap, and destruction
- Constant-time implementations throughout
Zero-trust key handling
- Keys never cross to the host CPU
- Capability-based access control
- Anti-tamper sensors with automatic zeroization
- FIPS 140-3 Level 3 design target for ASIC
CoreAnchor™ HRoT HARDWARE ROOT OF TRUST · FPGA-PROVEN
Every trusted system has a first instruction. CoreAnchor HRoT makes that instruction unforgeable: an immutable boot ROM measures each firmware stage, verifies its digital signature in hardware, and only then releases the CPU. It is proven on real silicon — Zynq UltraScale+ class and Artix-7 class devices — and its attestation verdicts can gate live workloads, starting and killing containers in real time.
Measured, verified boot
Immutable ROM, hardware-verified secure boot and firmware verification, and measured boot with TPM-like PCRs — every stage proves itself before it runs.
Device-unique trust
eFUSE key storage and a device-unique identity make every unit individually attestable. Remote attestation reports what booted, on which device, with cryptographic proof.
QCore Trust Suite EIGHT PRODUCTS · ALL DEMONSTRATED LIVE ON SILICON
A productised family built on one idea: the most secure key is one that never exists as stored data. PUF — a physically unclonable function, a fingerprint burned into silicon by physics itself — lets these products derive secrets on demand instead of keeping them.
CoreRoot™
A silicon-intrinsic trust engine — not a peripheral bolted on, but a capability the chip is born with.
CoreVault™
Keys sealed in silicon via a PUF-derived KDF. Never stored, never exported — regenerated from physics each time they are needed.
CoreSign™
Signing bound to attested hardware, including threshold distributed signing — no single device can sign alone.
CoreProof™
Attestation bound to the physical device, so "this firmware, on this exact unit" becomes a verifiable statement.
CoreZero™
A PUF-seeded, constant-time fuzzy extractor feeding on-die key generation. There is no stored root secret to steal.
CoreFabric™ AG
Full offline symmetric key lifecycle — generate, wrap, transport, unwrap, destroy — for estates where the network is never an option.
CoreAttest™
Continuous verification of device, firmware, and boot state across a fleet — trust as a live signal, not a deployment-day assumption.
CoreCrypt™
Cryptographic accelerator cores for designs that need protected crypto throughput at line rate.
Hardware security engineering
The same team that designs our silicon evaluates yours. We work at the level where attacks actually happen: power rails, debug ports, bitstreams, and firmware binaries.
- Side-channel
- Side-channel attack protection and evaluation — power and electromagnetic analysis resistance, designed in and then measured.
- Hardware trojans
- Hardware trojan detection across third-party IP and supply-chain-exposed designs.
- Boot & entropy
- Secure boot implementation, TRNG design and validation, and PUF integration.
- Debug & tamper
- JTAG and debug-port lockdown, anti-tamper architecture, and FPGA bitstream security.
- Firmware analysis
- Embedded firmware security analysis, static and dynamic: leaked secrets, entropy anomalies, risky imports, FSM encoding issues, and protocol fuzzing.
Questions we actually get asked
What exactly is a PUF, and why should I trust one?
A physically unclonable function is a fingerprint burned into silicon by physics itself — microscopic manufacturing variation that no two dies share and no fab can reproduce on demand. Our CoreZero™ reads that fingerprint through a constant-time fuzzy extractor and derives keys from it. The key exists only while it is being used; power off, and there is nothing to extract.
"FPGA-proven" — what does that actually mean?
It means the design runs, today, on physical development hardware — Zynq UltraScale+ class and Artix-7 class devices — executing real boot flows and real attestation, not simulation waveforms. The flagship root-of-trust build occupies roughly 18k LUTs, under 7% of a ZU9EG. We demonstrate on live silicon during evaluation.
Is Q-HSM FIPS 140-3 certified?
No, and we will not claim otherwise. Q-HSM is designed to FIPS 140-3 Level 3 as an ASIC target — the anti-tamper, zeroization, and key-isolation architecture is built for that bar. Certification is a formal process with a lab and a certificate number; when we have one, this page will say so.
Why machine-mode only on the RISC-V controller?
Fewer privilege levels, fewer transitions, fewer bugs. The Q-HSM controller runs a single, auditable machine-mode firmware with no user-mode surface to escape from. Combined with capability-based access control, the host gets exactly the operations it was granted — and nothing else.
Can attestation actually control workloads, or is it just a report?
It controls them. In our live demonstrations, CoreAnchor HRoT attestation verdicts gate container execution: a device that measures clean gets its workload started; a device that fails verification has it killed. Trust becomes an enforcement point, not a dashboard colour.
Watch it boot. Watch it refuse to.
Our silicon demonstrations run on real FPGA hardware: signed firmware boots, tampered firmware halts, and attestation gates a live workload in front of you.