zeroRISC
The security industry has long operated on a tacit assumption: complexity and secrecy are security. If an attacker does not know the implementation details of a security system, the argument goes, they cannot exploit its weaknesses. This is the philosophy behind most proprietary hardware security modules — and it has been repeatedly proven wrong.
RISC-V's emergence as a serious platform for embedded systems presents an opportunity to break from this pattern. The same open ecosystem that makes RISC-V attractive for custom silicon also enables a fundamentally different approach to hardware security: one where security properties can be independently verified rather than simply trusted.
The Limits of Security by Obscurity
Proprietary security architectures rely on attackers not having access to implementation details. In practice, this protection erodes through multiple vectors: reverse engineering, insider leaks, supply chain compromise, and the inevitable documentation that accompanies chip certification processes.
More fundamentally, security by obscurity concentrates risk. When a vulnerability exists in a widely deployed proprietary security chip, the vendor controls the disclosure timeline and the patch delivery mechanism. Customers have no independent means to verify the severity of the issue or validate the fix. This asymmetry of information is precisely the condition that allows vulnerabilities to persist in deployed hardware for years.
The history of proprietary hardware security is littered with examples. The Mifare Classic RFID chip, widely deployed for access control, used a proprietary cipher that was reversed engineered and broken. The HSM vulnerabilities discovered in 2019 affected multiple major vendors' products because the proprietary implementations had never received the level of scrutiny that open implementations routinely attract. Each incident followed the same pattern: obscurity delayed discovery, but did not prevent exploitation once an attacker had sufficient motivation and access.
What Open Security Architecture Actually Means
Open security architecture does not mean publishing attack tools or making exploitation trivially easy. It means that the security design — the threat model, the trust boundaries, the cryptographic protocol choices, and the hardware/software interfaces — are documented and subject to external review.
The key components of a verifiable open security architecture for RISC-V are:
- Published threat model: Explicit enumeration of assets, adversaries, and assumed capabilities
- Documented trust boundaries: Clear delineation of what code runs in what trust domain, enforced by hardware
- Open-source security firmware: Boot ROM and security subsystem code available for audit
- Formal verification artifacts: Machine-checkable proofs of key security properties where feasible
- Public test suites: Test cases that validate security invariants, usable by implementers to verify their instantiations
The secret keys and device-specific credentials are never published — that would indeed be a security failure. What is published is the architecture that protects them. Security through architecture, not through secrecy of architectural design, is the goal.
The Community Audit Advantage
Linus's Law — "given enough eyeballs, all bugs are shallow" — applies to security code as well as feature code, but with a critical caveat: the eyeballs must be specifically looking for security issues, not just functionality. Open security architecture enables the formation of a dedicated security research community around a platform.
For RISC-V, this community effect is already visible. The OpenTitan project has attracted external security researchers who have identified and contributed fixes for issues that internal teams missed. This is not a criticism of those teams — it is a demonstration of the multiplicative effect of open review on security outcomes.
Academic research on RISC-V security is also accelerating because researchers can study the architecture without the legal restrictions that come with proprietary silicon NDAs. Papers on RISC-V privilege escalation, PMP bypass techniques, and side-channel characteristics appear regularly in top-tier security venues. While each paper identifies potential vulnerabilities, the net effect is a platform that receives more security attention than any proprietary equivalent at the same scale.
Formal Verification: The Highest Level of Assurance
Open security architecture enables an even more powerful validation technique: formal verification. Formal verification uses mathematical proof techniques to establish that a system satisfies a security property for all possible inputs and execution paths — not just the cases covered by tests.
For hardware security primitives, formal verification is increasingly practical. The lowRISC team has formally verified key security properties of OpenTitan's boot ROM. Academic groups have formally verified RISC-V PMP semantics. As tooling matures, formal verification of security firmware on RISC-V platforms is becoming a feasible part of a high-assurance design process.
Proprietary hardware security chips cannot benefit from this trend because the design details are not publicly available for formal analysis. Open architectures, by definition, can be formally analyzed by anyone with the necessary skills and tools.
Practical Benefits for Chip Designers
Beyond the philosophical arguments, open security architecture delivers concrete engineering benefits. When the security architecture is documented, integration engineers can reason about security properties without requiring a direct line to the vendor's security team. Audit and certification processes are faster when reviewers have access to design documentation rather than having to extract it through the certification process itself.
For customers deploying these chips in critical applications, auditability translates directly into procurement confidence. A hospital network selecting processors for medical devices, or a defense contractor evaluating chips for communication systems, can conduct independent due diligence on an open security architecture in ways that are simply not possible for proprietary alternatives.
Common Criteria evaluations, FIPS 140 certifications, and similar standards increasingly recognize that openness and auditability are security properties in themselves. Evaluation bodies can conduct more rigorous assessments when design documentation is complete and source code is available for inspection.
The zeroRISC Approach
The zeroRISC platform is built on the principle that security claims without verifiable evidence are marketing, not engineering. Our threat model is public. Our security firmware is open source. Our test suite is available to anyone implementing compatible hardware.
We maintain a responsible disclosure program that invites external security researchers to examine our platform and report findings. Confirmed security issues are remediated and disclosed in accordance with industry norms, and contributing researchers are credited publicly. This is how security by community works in practice.
We believe this approach will ultimately define how serious embedded security is done in the RISC-V era — not because we think openness is philosophically superior, but because it produces better security outcomes for the engineers, operators, and users who depend on these systems. The question for a chip designer choosing their security architecture is simple: do you want security that has been reviewed by your internal team, or security that has been reviewed by your internal team plus the global RISC-V security research community?
