Prof. Sylvain GUILLEY
Short Biography
Sylvain Guilley is General Manager and CTO at Secure-IC, a French company offering security for embedded systems. Sylvain is also professor at TELECOM-Paris, research associate at Ecole Normale Superieure (ENS), and adjunct professor at the Chinese Academy of Sciences (CAS). His research interests are trusted computing, cyber-physical security, secure prototyping in FPGA and ASIC, and formal / mathematical methods.
Since 2012, he organizes the PROOFS workshop, which brings together researchers whose objective is to increase the trust in the security of embedded systems. Sylvain is also lead editor of international standards, such as ISO/IEC 20897 (Physically Unclonable Functions), ISO/IEC 20085 (Calibration of non-invasive testing tools), and ISO/IEC 24485 (White Box Cryptography).
Sylvain has co-authored 250+ research papers and filed 40+ patents. He is member of the IACR, the IEEE and senior member of the CryptArchi club. He is an alumnus from Ecole Polytechnique and TELECOM-Paris.
Talk Title: Security analysis tools against cyber-physical attacks
Embedded systems are the cornerstone of security, because they safeguard the “secret keys” and can be attacked either from the top (cyber) or from the bottom (physical layer). However, unfortunately, embedded systems are, by essence, programmed at “low-level”, hence security vulnerabilities can hide in any detail! Thus, the most effective way to find bugs and increase assurance is to resort to specific tools.
From the normative point of view, there are multiple standards which are out to stress that cyber-physical shall be considered seriously. For instance, NIST SP 800 series, EN 303645, etc. explain what shall be undertaken from the quality, organization, process, management standpoints. But few standards come up with an operational security testing methodology, with the notable exception of ISO/IEC 17825. In this presentation, I will apply the philosophy of this standard, namely that it is futile to test all attacks, but that it is more productive to ascertain attacks preconditions that are not met in the first place.
Namely, I’ll introduce the following test methodology:
- Check applications structure (e.g., is TEE calls following GP recommendations?)
- Check software (e.g., is it constant-time?)
- Check hardware RTL (e.g., are all sensitive variables protected?)
- Check hardware GDSII (e.g., are there sensitive glitches?)
In conclusion:
It is possible to set up a methodology to verify implementations from end-to-end. Notice that this methodology is the reverse direction compared to Common Criteria composite evaluations. Our methodology, based on a non-regression approach, allows to pro-actively detect vulnerabilities (the sooner, the cheaper). All in one, we promote a paragon of DevSecOps methodology: develop with security in mind.