Hardware Security By Design
summary
Panelists argue that real progress comes from concrete practices not platitudes: teams adopt pre-silicon security verification and automation, use formal verification is not bulletproof while accepting its limits, and prioritize recoverability like over-the-air updates within 48 hours so field fixes are possible. They call out missing tooling for side‑channel and fault injection simulation, warn about fab supply‑chain Trojans and focused‑ion‑beam remanufacture, and point to DARPA POSH and roughly $100M funding as a catalyst for usable open hardware.
AI-written summary · about
chapters (8)
- 0:00Start
- 0:38Format of the Panel
- 2:50What Is Bio Hacking Mean to You
- 6:36Hardware Security Dark Ages
- 17:33Can the Security Teams and the Design Teams Be the Same Team or Do They Have To Be Separate
- 19:11What Are the Most Pressing Threats To Protect against
- 21:07What Criteria Do You Use To Measure Security and How Do You Know You'Re Done and Ready To Deploy
- 40:35Rules of Hacking
related talks
42mPanel: The Right To Secure; What, Who, How And Why!
27mSecurity: The Thing That Everyone...
29mEnabling a secure IoT from design to deployment
50mRunning in the Shadow: Perspectives on Securing the Software Supply Chain
43mSecurity By Design
03mBridging the Gap: The Convergence of Hardware and Software Security
40mHardware Security Is Hard: How Hardware Boundaries Define Platform Security
44mMake It Fixable