 Elle était une étudiante de plein d'ingénieurs en France. Elle a eu un maître d'école polytechnique et d'un PhD de télécomparie. Durant le PhD, elle a étudié différents attaques statistiques sur les chiffres symmétriques. Elle était l'une des 4 fondateurs de la team de la sécurité et de la cryptographie de Jean Plus. Elle a ensuite étudié aux États-Unis et a travaillé pour la recherche cryptographique. Elle a été le directeur de l'IECR. Maintenant, elle est la technologie sécurité de la fédérale d'Altrombos. Elle est responsable pour de nombreuses activités de recherche, incluant crypto et PASQuANTUM crypto, pour analyser la surface et les mesures de contente et la structure de sécurité pour nouveaux produits et services. Alors, elle a récemment pointé une personne pour les 5 risques. Le Comité de Sécurité Fondation de la Fondation et elle va présenter un travail dans ce comité. Donc, s'il vous plaît, joignez-moi à Eleanor. Merci beaucoup pour cette introduction. Je vous souhaite que le micro soit en train. Ok, bon, merci. All right, so indeed, my name is Helena Hanchou and I'm a Rambus Security Technologies Fellow. I'm also the RISC-5 Security Standing Committee Chair and it's my pleasure to chair that committee because it is security related and that's one of the topics that we like to work on at Rambus and that this community likes to work on as well. So let me try to give you a little bit of an overview of what RISC-5, the foundation does and how that relates to security and what the security committee is trying to do as well. Okay, does that work? Yes, perfect. So here's a little bit of the outline of my talk. Just a sec, so I know how much time I have. First I'll try to say a few words about the RISC-5 foundation itself when it was created and how it started working, what the current status is of the specs and stuff and then I will talk about the Security Standing Committee creation and its charger and the task groups that we currently have that work on security. I'll say a few words about some DARPA activities that some of us in the foundation have which is not directly related under the umbrella of the foundation but still related to the same topic. I'll talk about the speaker program we have mentioned some academic and industry initiatives around RISC-5 and then maybe some open problems and research directions that you might be interested in hearing about that you might get interested in working on and hopefully you would then join us and to bring the work to the foundation as well. All right, so first things first, RISC-5, pronounced RISC-5 is a free and open instructions at architecture enabling a new era of processor innovation through open standard collaboration. That's the official line of the RISC-5 Foundation. It was founded in 2015, so for about four years ago. In the meantime, it already has more than 300 members. This includes both organizations and individual members. As an individual, you can also join the foundation and have access to the specs and work on everything if you'd like to. It's open, it's a collaborative community of software and hardware innovators so both sides are being looked at. The base, ISEID, itself, was born in academia and in research. It was put together by Berkeley and then given into the foundation. It's a new level of free, extensible software and hardware freedom on architecture. We hope to be paving the way for the next 50 years of computing design and innovation and as I said, members of the foundation can have access to and participate in the development of the specs, of the extensions and all the related hardware and software developments and ecosystem. Recently, somebody told me, when you make slides like this which are full of words and you have to read all of that, nobody really understands anything, so you should highlight what you wanna say. Okay, so let's go. There we go. It's free, open, open, free. Lots of freedom and the website is here. Okay, so that's risk five. Let me give you a few words of intro on what the basis for the work is here. So the first thing that was worked on was the risk five instructions at manual. It has two volumes. The first one is volume one called the user level ISEID. It was mainly edited by Andrew Waterman and Krister Azanovich and the version, the most recent version that was, the first version that was brought into the foundation was version 2.1, 2.2, sorry, in May of 2017. It was drafted in May of 2017. It's a Creative Commons attribution international license so you can use it, open three. And it was originally derived from a version 2.1 which was written by Andrew Junsuk, David Patterson and Krister Azanovich. So what does it actually contain and do? Well, there is first of all a base instruction set architecture. So it has different sizes, register sizes. You can work on a 32 bit version. You can work with a 32 bit embedded version which has a slightly reduced version of the instruction set. 60 full bit and 128 bit. And then on top of that, we have so called extensions. So there's a number of different such extensions that are being worked on. One of them is called, they go by letters. So one of them is called the M extension which is for multiplication and division. Another one is called A for atomic instructions. Then you have a few different ones on floating point operations. So single precision, double precision, quadruple precision and decimal. You have a compressed instruction set extension. You have bit manipulation extensions and you have, there's a bunch more. One of them is important for us specifically for cryptography. One of them is called vector extensions. All right, so this is the first version that was contributed. And now what happened next, move forward, fast forward a little bit from that first version is that about two months ago, in June, on June 8, this first volume one user level ISO was ratified by the foundation. So it's now a stable ratified adopted specification that everybody can use and is officially promoted by the foundation. So the difference between the ratified one and the previous one, let me show you what it is. First of all, there's a little bit more work that went into it in the last two years. Most notably, it went from 145 to 236 pages. So a lot of more stuff. It does show the ratified parts and it has additional extensions. So this is a little bit small. You might not be able to read it completely but if you look at the spec on the website, you can see the ratified portions. Some of the extensions have already been ratified. The others are still being worked on. So they are called drafts. One of them, the one that we're interested in, the V extension you can see is still a draft. So that makes Rich over here very happy because every time he wants to build on it, he has to go back and look at what they changed last week. But it's progressing in parallel. We're working at the same time. And so we're trying to get these things towards ratification as we go. Then there's the second thing that has been ratified at the same time as the base level ISA, which is the volume number two, which is about privileged architecture. So the first one is the user level interface. But below that, you have levels of privileges that certain, where you have certain permissions and certain rights that get executed at those levels. And this is what the second volume talks about, which was ratified at the same time. It was edited by the same people, has the same license attached to it, all that's the same. And what it does show is the following. Sorry. It does define three different modes. In addition to the user mode, it defines the machine mode, which is the lowest level, which is very close to the hardware, which is usually implemented in hardware. The supervisor mode, which can be done in hardware as well, but you could start being able to go into software a bit more. That depends how your architecture looks like. The hypervisor mode, and then finally the user mode, which is in the previous volume. So far, we have two modes that have been ratified in June. This is the machine and the supervisor mode. And the third one, the hypervisor one is still in draft. So you can still contribute and make comments and provide feedback. And if you join the foundation, you can work on getting that towards ratified as well. All right, so three modes here, plus one user mode. This is what we have so far in the foundation, as the base for everybody to work on. All right, so I usually get the question, but okay, this is great. This is paperwork. Do you guys have anything for real? Yes, we do. So on the website, if you go on the RISC-5 Foundation's website, you will see a list of 65 cores that people have been working on. And I'm sure there's more out there, if not all of them are listed here, then please let us know if you're working on this as well. Give us more references so we can list them and give people pointers to your work. But here you will see 65 cores that are already available. Many different companies are working on them. There's cores by companies such as Andis and Sy-5 makes them available for you to use. And Microchip has some, there's plenty of different companies and there's also universities. Etihad Surich, for example, has a few of them that they built. MIT worked on them, Berkeley worked on them. So plenty of things to play around with. One little side note here. None of these have passed the RISC-5 Compliance Suite yet. And this is for a very simple reason because this Compliance Suite is still in development. So it's a little bit difficult to have already passed something that's not completely finished. We're working things in parallel as soon as the Compliance Suits and foreign aspects have been finished and ratified and everything, then we will start being able to have the cores pass those suites as well. All right, so a bunch of cores available. The other thing that is useful as well, useful to know, is that you have a number of tools and software associated to RISC-5 available that is listed on the RISC-5 website as well. So, for example, if you look for simulators or debugging tools, compilers, spootloaders, OS and OS kernels, compilers, you name it. All of that, you can go on the website, click on the link and see what other people are working on, what they've put on their own websites and you can, some of it is open and free, some of it is more commercial, but you will always find something that's useful to be able to work on. And very new to this environment, we also have a link now on that website for security software. There's not a whole lot yet there, but I've listed here in the little square the two things that have been posted there since the last month or so. So, one company called Hex-5 is working on an SDK there and I'll come back to that on what they do. And the Keystone project has posted their Keystone enclave there, so you can go and look at that as well. All right, okay, so this is globally what the foundation does, everything that you have access to that you can look up. Now let's get to the real topic which is RISC-5, how about security? What about security? So, let me go back in time a little bit and talk to you about January 2018. January 2018, Spectre and Meltdown, that was the oops moment. So, suddenly people working on processors realize there's something there that shouldn't be there. Namely, if you look at speculative execution, branch prediction and all these things, you suddenly realize that you're leaking information through, for example, cache timing side channels because you're trying to speculate about something that will happen in the future. You start looking at data that you're not supposed to be looking at because you haven't computed the previous result yet, yet you're already looking at something that you shouldn't be looking at. And so, by this little magic, suddenly data gets exposed that nobody should have seen. And so, this was a big realization for the foundation saying, oh wait, we are working on open free processors and there's this thing going on whereby other processes are being greatly hacked and broken by these side channel attacks, a new form of side channel attacks. What shall we be doing about this? We need to do something about it. All right, so, this was exactly what led to the creation of the security standing committee, which I have the pleasure of sharing. So, this happened around July timeframe and by the time we got our publications together and knew what we wanted to work on, it was about July and that's when the security standing committee was announced. So, July 2nd, press release, Rescribe Foundation announced the security standing committee creation calling for participation. So, I had said back then, apparently, that security is one of the fundamental issues in our connected world, it's told too, and that we would like to address existing and emerging threats. And Joe Kinnery, which I will come back to as well, was talking about the event of a new compute platform that has formal methods at its foundation for processor correctness and security. So, it's all about proving and formally assuring security during hardware development. How do you make sure that you can formally say my design has these properties and prove it? Okay, so, this standing committee has been created about a year ago and has been working on different things since then. Let me show you what the mandate of that committee is when it got created. So, this is compared to other committees in the foundation. This is a permanent committee. The non-permanent ones are called task groups, and I'll give you two examples of what we're working on. But this one is a permanent one. So, the permanent one looks at things that are going on in the security world. What should we be working on? It can recommend, for example, to create task groups which then go and write specifications, specifications, drafts that then go towards ratification. It is meant as an ideal vehicle for the security community. So, this community here, it liaises with other committees inside the foundation but also outside the foundation. So, for example, we're starting discussions with global platform as one of them. We might be talking later on to TCG and to FIDO and other committees like that to see where we intersect and how we should be working together. We have a mandate to create an information repository, a new attack trends, countermeasures, and stuff that's going on in the world of security that is important to the foundation and that people should know about. We're identifying top 10 challenges and security for the risk-buy community and I guess very top, top up there is all about side channel attacks, the new version of it, I would say. We do propose task groups, as I mentioned. We are here to recruit security talent, so if you're interested, please join us, work with us. It's a lot of fun, it's challenging, not easy at all, but it's a lot of fun. And develop consensus around best practices for maybe even the smaller devices like IoT and embedded systems. Okay, so mentioning task groups, we already have created two task groups that deal specifically with security. One of them, the first one, is the cryptographic extensions task group. This one is chaired by Richard Newell from Microchip, sitting right here. So if you have any questions, please ask him. The vice-chair that has recently been nominated and approved is Derek Atkins from Secure RF. And these two great folks are trying to get us some crypto extensions on top of the vector extensions. So the charter that is proposed in this task group is to build extensions on top of vector extensions that would be useful for cryptographic algorithms. The intent is to have a base and an extended version of that. The base one would have low cost instructions for acceleration of the most traditional and common algorithms. And the more evolved one would have greater functionality. There would also be reserved encodings for other types of algorithms, all sorts of types of algorithms because there's a bunch out there so that we can get better security performance out of it. It includes both symmetric and asymmetric algorithms in its mandate as well as other primitives related primitives such as hash functions, message digests. And the committee will also at some point be looking at random numbers and secure key management. Now remember that the foundation works at the instruction set level. So these kinds of committees do not define how you actually do, for example, generate random numbers, but it defines how you build your random number generator into the system, how you have access to it through the instruction set. Is that right, Rich? Okay, so remember that you stay at that level and don't necessarily look at how it's being implemented at the hardware site. Okay, so a little bit of status update on where this task group is at. Right now it is working on AES instructions for three key sizes and that's done. The SHA-2 instructions are being looked at for both 256 and 512, which is almost done pretty close. For both of them, there is one solution that lets you do a one round approach and a full round approach for AES and the SHA-1 is a 16 and a full round approach. So the solutions are being worked on and are pretty much done. Now we're in the step of needing to convert that into official specs. So we know how we wanna do it. Now we have to draft the specs and then get the specs ratified at some point. The group has also been looking at prototyping public key algorithms on top of the base instruction set, so looking at how to do long integer arithmetic and there is an implementation proof of concept that was looked at, so just to make sure we can do it and it's available and it works. And some future directions here are the more lightweight approach maybe to this entire thing. Remember that this is based on vector extensions, which is quite a broad set of extensions. So one possibility would be to look at maybe just a subset of the vector extensions to make it lighter or to completely remove the vector extension dependability and just include some smaller instructions for that instead. So there's an approach that was proposed very recently by the University of Bristol called Xcrypto which proposes scalar instructions, rotates like smaller style instructions to have the software, the crypto software run faster and Bristol has recently joined the foundation is now part of the discussions to see how we could do all of that together. Sorry. And I'm hearing that Tilly Comparitek also expressed some interest in this kind of research. If you're working on things like that, if you wanna talk to us, talk to Rich, please do so, join the foundation and come work with us. All new ideas are really welcome. All right. The second one, second task group we have currently is one that is looking at how to build a trusted execution environment on top of the RISC-V architecture. This one is led by Joshi from NVIDIA and Nick Cosifidis from FORTH. And what they're trying to do is really define an architecture spec that will support trusted execution on top of RISC-V processors. So they are looking at providing implementation guidelines, recommendations and to develop kind of the components that you will need to have a TE available such as compilers, simulation models, hardware, software components. Because you built up, it's a bigger system than just the processor. What do you need for that? What is mandatory for that? What is necessary, sufficient and so on. So in terms of where they are at, currently what they're looking at is that the first thing is a PMP model that they defined, physical memory protection. It is based on the privileged spec on the latest version 1.12. They're also looking, same thing, how to securely divide up the memory and how to protect it securely at the outer limits. So that's called the IOPMP. It's a proposal stage version 0.1. And as a next step on the hardware side, they will be looking at control flow integrity extensions. What can be done there? On the software side, the work that's being done is a secure monitor architecture. There's a document being put together on secure boot architecture. So you recognize all the traditional notions that you have around trusted execution. We're trying to architect and formalize that. So the first secure boot architecture has signature verification as a basis and then some optional extensions for further on for key management, inserts, revocation, attestation and things like that. And the other part that's being worked on and looked at is the TE APIs. So an API to the other parts of the system. For example, between trusted applications and the US, between two trusted applications, how do they talk to each other? How do you attest a trusted application? How do you talk between a trusted application and a secure monitor, et cetera? So all of these APIs are being looked at and discussed and debated and hopefully drafted and standardized at some point. Oops, sorry, everybody awake now? Okay, so on a slightly different note and subject, there is another activity going on which is not directly under the umbrella of the risk by foundation, but very deeply related to it. This is driven by Joe Kinnery from Galois. He is also the vice chair of the security standing committee. And he's involved in a lot of different darker projects, one of them being the SIS project and I forgot what the acronym means, but S is probably security and then the other S and H are software and hardware. So they're looking at how can you build secure systems? How can you kind of model secure systems with security properties and how can you reason about them? How can you formalize that and then prove that your system is secure? One of the things they look at is a formal spec language for hardware design called Lando. And this one has four sub languages, a system spec language, an architectural language, product line engineering language and a security property language. So you can specify what your security properties should be, what they should look like and then you can reason about it and you can verify. That's the work that they're doing. So not all of this is public, not all of this will be public in the future, but as DARPA allows Galois to publish some of this, it will become available and they will contribute it into the RISC-V Foundation as well. They're also working on a domain model for specifying security properties. So for example, they've started by formalizing the NIST CWEs and among those mostly the ones relating to buffer and memory errors. So this is all going in the direction of formalizing vulnerabilities and checking that they're not there in your design. And again, as these things become publishable and DARPA allows to publish more of it, these will get contributed into the foundation and everybody will be able to look at it and use it. Along the same lines, they're working on a tool suite that's called Bespin for formal reasoning. And a sub-system of that tool suite has already been published and made available to the RISC-V formal group. This part is called GRIFT and it stands for something like Galois RISC-V formal tool or something like that, close. But it's a part of this larger system, tooling system called Bespin where you can use the tool to formally prove things. And finally, they work on many different things but the ones that are interesting for the RISC-V foundation are the ones around platform specs and security-enriched ISAs. So what they've done recently, I believe it was at DEF CON this month, they have started showing a secure voting machine platform spec, which has certain security guarantees in it. So it's meant to be open for public review. It's meant to be offered as a game to go against and to try to attack. It's a voting machine so everybody knows that the state of voting, secure voting machines is an interesting state these days. So this is an attempt at trying to make a secure one if you can go and try to hack it. If you find interesting results, please feed that back to them. We will incorporate that, they will do that and then incorporate into the platform specs as they go and build better systems. It's a bit of a hackers and builders game. They're also working on six other platform specs based on RISC-V SOCs. The six that they're looking at are Rocket, Boom, Piccolo, Fluid, Bassoon and Risky. If you've never heard about this, go on the website and look at them. These are the ones that are mostly being worked on by MIT, Berkeley, Etihad, Zurich, I believe, and then there's two, the two others, I don't remember which institution proposed them, but they're like very open, you can look at how that works. And later on, hopefully, we will see some of the platform specs being published as well as DARPA gives authorization to do that. Okay, so this is the kind of more formalization security proof approach in hardware design that this part of Galway is working on. Okay, so we also have a speaker program in the security standing committee. We have so far invited a number of people as we went. Remember, we have about one speaker per month average, I would say. We alternate between a business meeting and a speaker program in the committee meetings. So this means that every other time we have a guest and every other time we talk about, okay, so what's new in the world? What should we be looking at? Is there a new task group we should be creating? What should we be doing? Okay, so the speakers we've had so far, Gernot Heizer from data 61 on timing and tax and an augmented form of the instruction set. And I'll come back to that a little bit later. We had Dayali from Berkeley on the Keystone project. José Renaud Esperanto on timing, attack, mitigation ideas. You can see that most of the topics are around how do we get rid of these annoying side channel attacks. John Giger was talking about TEs and what these things look like. Nicole Fern from TortugaLogic has been presenting on security oriented verification tools. It's kind of a tool that allows you to check at the hardware level whether some of the security vulnerabilities that you would like to avoid are really not there. Daniel Genking has been talking to us about foreshadow. Stefan Mangat and his team have been talking to us about specific security ISA extensions. I'll say just a couple more words about that later. And Ben Marshall, I already mentioned him from the University of Bristol, has been talking to us about his ex crypto extensions to the ISA so that faster crypto can be built. If you would like to give a talk on risk five security topics, your name goes here, please come talk to us. We can set up a time for you to talk to the group. And then we can talk about the topic that you'd like to present. So we're trying to collect all the information about people, institutions, academics, organizations that are working on risk five and security so that there's kind of a little bit of a centralized information repository about all these initiatives. Okay. If you, other ongoing security initiatives that was independent from the RISC-I Foundation, again, there was a security contest but it is related to risk five. So I wanted to mention it. There was a hackathon at DAC last year where a group of people have organized kind of a hardware bug hunting. And because risk five specs and everything are open, they chose it as a platform that was easy to implement fake bugs into if you want and then give them to everybody to go off to try to see if they could find them. So they had a systematic bug construction approach for bug hunting and along the way, apparently, they also found a couple of native bugs in some of the risk five processors. So open and available to everybody does not necessarily equate security. It helps a lot. It's a good starting point, but there can still be issues and bugs can be found. So this is something that we should also keep in mind. And you can go online and check it out and ask them what kind of bugs they put in there for people to hunt after. Another ongoing security initiative is still in the same area. Security contest, this is all new. And again, if you're interested, please talk to Rich. It's being run by TALIS and Microchip. It was announced on July 15th. It's a sort of hackathon. They're looking for open source submissions on a Microchip FPGA where you propose a construction with security countermeasures. It's based on Zephyr where you're allowed to make a limited number of changes to the compiler. And the deadline for submissions is September 15th, so hurry up. And the idea is to try to come up with a security implementation and a security proposal that will protect at least against the five classical, very classical attacks which are listed here. So it's about corrupting function pointers, buffer overflows on the stack, corrupting function pointers, both on the heap and the stack, and things like that. So if you have a proposal, please submit it to the contest. It's supposed to run on the Microchip FPGA and TALIS, I believe, is someone that will be assessing security on it. All right, a few more initiatives. On the academic and national labs side of the world, we have mentioned already, but I'll mention them again. The University of Graz is working on extensions for security, mainly around trying to counteract side-champ attacks, control flow integrity, and trying to work on secure memory access. So they built extensions for that, and I believe all that work is pretty much public. So you could either talk to Stephan and his team which is sitting somewhere in the audience as well, or you can look up their papers that they've published already. The University of Bristol, which I mentioned, ex-crypto extensions, and Telecom Paris Tech also expressed interest. I don't know that they have published papers yet, or if they have, please send them to me, so I can listen here. But there's interest there as well. Another initiative that was presented at the workshop in Zurich this year, earlier this year in June, was from Seu Aletti. They're working on a secure processor with essentially everything authenticated and encrypted in there. So all of the resources are essentially secured, functionally secured. Buses, bus access, buses memory accesses, data path, instruction path. Everything is nicely authenticated and encrypted. The slides are online at the Zurich workshop. You can go online and see it there. They've, I believe, also published a paper on it. They will be giving a talk, hopefully to us later this year, but not quite ready yet. But okay, it is not super fast, obviously, if you encrypt and authenticate all of these lines, but it allows for a very secure implementation of a processor if you have applications for that. A couple more initiatives around secure enclaves, based on risk five. One of them is called Sanctum from MIT, and that is a basis for the Keystone Project from Berkeley as well. They're slightly related. There is another initiative called Open Titan from Google, with five base as well. There is, remember, at the beginning, I had a slide on security software stuff and Hex 5 was mentioned there. So what they do, what they propose is a multi-zone TEAPI, and that one's available for you to look at and review. So they propose a way of having multiple different secure applications run at the same time, or at least on the same platform such that they can't kind of attack each other. We do have a few initiatives as well, so if you wanna hear about our Crypto Manager root trust, you can have a look at the demo next door over coffee or lunch. And Joel Wittner, who might be still sitting here in the audience today, he says no, he says yes. Joel is sitting here. He gave an invited talk yesterday at FDTC. He could tell you all about how to run mutually distressing applications on a RISC-5 embedded platform such that they can't essentially attack each other. We also have an initiative going on. It's not a secure enclave, it's just a processor here, but initiative going on, which is DPA-resistant, DPA-resistant RISC-5 CPU, by Mike Hutter, Elke de Mulder, and Samata Gummala, and this has been published and talked about before at the RISC-5 Summit last year, as well as an invited talk at DAC this year, earlier this year, and next month, there's a Lawrence workshop where Mike Hutter is probably gonna say a little bit more about that as well. Some of them are in the audience as well, so you can talk to them about that, okay? All right, so these are kind of the initiatives that I wanted to talk about a little bit on what exists today. Everything the foundation does, all the task groups, the things that are either commercially or openly available that you can play with, software, ecosystem, and all of that. Now, let me, in the last few minutes of this talk, maybe talk a little bit more about what still needs to be done. Remember that a foundation is a standard like a standardisation organisation, and so it does advance at a certain speed. It doesn't go super fast, but it does steadily advance. So if you wanna contribute, please come and help us. And these are maybe some of the topics that we still need to work on. Okay, first one, big question is how to mitigate micro-architectural flaws. So what we found out over the past year and a half is that beyond the original side channel attacks we talked about 20 years ago, which was DPA and EMA and all of that, differential fault attacks. There is another complete set of side channel attacks. Some of them yet to be found that will, is gonna hit processor manufacturers and developers as we move forward because there's so many things still to be found. So the question is how do we really try to counteract these, because most of these happen at the micro-architectural level. The foundation is working at the instruction set level. How do we make sure that we can specify something, help people understand how to build better systems without necessarily completely specifying what works at the, what is done at the micro-arch level? So that's one of the big questions that we're trying to tackle. We've started discussing that we couldn't necessarily do it at the ISO level, but we could describe platform specs which go a bit further and would give you some indication and some hints of how to add special instructions that would help mitigate some of these things. So that's kind of the direction we're trying to go. So how do we do better than proprietary micro-arch? How do we publish more, explain more, yet leave the actual implementation free for the implementer and the organization to do whatever they want? So we specify one level and what comes below is open to anybody to do what they want. Big question. Some ideas on how to mitigate these have been proposed by people that have written papers about it and have published about it. So here I'm listing a few ideas and directions that have been proposed. Now we're trying to look at how do we build these ideas into a platform spec? How does that work? So Gernot, I mentioned him before, has looked at something called the augmented ISO. He proposes a way of adding cash flush instructions into a system as well as trying to partition the memory in ways that different processes cannot access each other's private information. So it's a little bit difficult to build, but that's one of the directions we're trying to go. José Renaud from Esperanto also had some timing attack mitigation ideas in there. He was going down a bit more the path of kind of adding tags with security classifications to your elements so that you could kind of give some security property to each of them and follow the properties through the flow. And recently at the secure enclaves workshop in Berkeley last month, c'est-à-dire, sorry, it was this month, Chris Fletcher from the University of Illinois proposed something called speculative taint tracking, so which is again some idea of tainting registers and defining corresponding update policies such as if one register is tainted and you mix it with one that's not, then both of them are tainted so you kind of have to follow the flow through your design, make sure that your specific information that you want to keep private, confidential or authenticated will have the same properties as you go through the process. So these are some examples of works that are being done and we're trying to figure out how to add this into our main specs. Another big question that we're trying to deal with and that comes up more and more is what about security certifications? So should the RISC-5 Foundation actually be involved in it? And if so, how? The question comes up because being at the instruction set level, we don't look necessarily at how the implementation is done. That's not the mandate of what we do. So how do you make sure that you can certify for security if you're not looking at how the implementation was done and how it leaks or not? That's a good question. So we've had, the first thing that we're doing is that we're creating formal specs and compliance test suites, but this is only, I would say, a functional spec compliance aspect of it. So it has a certain function and that function will be realized. Functionality will be realized. That doesn't tell you anything about how much it leaks or not. So how do you certify, given that the micro-arcs specs are kind of out of scope and that every flaw we've seen more recently is related to that side of things? Good question. So we started some discussions with different evaluation labs, security labs that are, or other organizations that are proposing different schemes and we are trying to see if there could be certain security levels that we could define that would maybe not necessarily look at the exact implementation, but at least from a functional perspective, prove that the security properties are done right at least. So the two that have been proposed so far are CESAP and PSA for more IoT-oriented devices. One of them, interestingly enough, is driven by ARM, but my understanding is that you can perfectly submit a risk-5-based design to this scheme as well. So discussions about how do we do this? How do we even approach this? Any good ideas? Please talk to me. So this brings up an interesting question as well, a question that I got at one of the recent workshops about, well, how do you position open-source versus security certification? Because if some of you, most of you, I'm familiar with common criteria and how that security game works, and there's something in there called the Jill Tables in which you get points if your design is actually not accessible and is hard to find. So essentially, your design is more secure in some sense if you don't make specs available and it is hard to discover what's in your product. So if we're talking open-source, this is going the exact opposite direction. You benefit from everybody being able to look at your design, making comments, you find bugs, and you can improve, but you lose points on the Jill Tables in the common criteria game. How does that fit together? That's a question I got recently, and I don't know that I have a good answer to that yet. So open-source was just some form of, I'm calling it obscurity, which is a little bit over the top, probably here, but it is a form of obscurity to say you get more points if your design is harder to find because nobody has seen it before and never will. Good question. All right, and then the other direction is assurance. So I've talked about that a little bit before. Formal verification, hardware, security, properties, and guarantees towards that. I've mentioned a few tools that Galois is working on, lando, or specs and tools, lando, bespin, and grift. There's other things going on in this world on security assurance in that form. I've listed a few things here, which are not just risk five related. They're broader than that, but please see some of these companies qui sont ici à chess this week as well. They have interesting things to propose. For example, riskure has a kind of software source code analysis tool that's called true code. Secure IC has something a little bit similar, but I believe at the hardware level called virtualizer. Fortify IQ has a tool called trace IQ, which is trying to see if some of your designs are resistant to power analysis or not. Enterturga Logic is a company that proposes a tool called Radix that can analyze your RTL and see if certain security vulnerabilities are present or absent and helps you design better at the RTL level. I'm sure there's plenty more stuff going on. This is kind of the things that I'm mostly aware of if you're working on something else that I haven't talked about, or that I haven't listed. Please speak up, and we'll be happy to to include information about what you do here. All right. Couple more minutes, one or two more ideas that you could be looking at or working on. What about risk five and post quantum crypto? We're going the first step. We're a little behind, so to speak, looking at algorithms that were done 10, 5, 10 years ago. We're doing that now. But what about the future? What about post quantum stuff that's coming up? And there were interesting presentations about it this morning. How do we address it as the risk five foundation level? Should we be looking at addressing it at the vector extension level? Does that even make sense? Should we specify completely new stuff like inner products that would make some of the constructions go faster? Is this necessary? Is this sufficient? Is it even going to be useful? Will it gain performance? Should we do it? Should we not? If you want to work on this and propose a group, please do. Should we be doing any specific extensions for lattices, codes, super single or isogenes? How do we do that with the current instructions and what else do we need? Another open research question. Okay, almost done here. So I think I've given you a little bit of an overview of everything the foundation does. The tools that are available, specs that are available, work that the task groups are doing right now, future work that we could be looking at and most importantly, the open problems is how to really deal with security when security is done at the implementation level. How do we do that? Any ideas are welcome. We have some ideas and we'll be coming up with interesting platform specs but everything relating to implementation level leakage, we need to think about how to address that. So open source, I would say in general is a great approach, even if you lose a couple of points on the Jill table. There's many new opportunities. There's a lot of stuff happening. There's a thriving RISC-5 ecosystem. Please do look at the open problems. Please continue working on everything and let us know of your results. There's many good ideas already, a lot of initiatives but still many things to be done. So this is really a call to action and again, I'd like to thank the organizers of chess for inviting me today to be able to give this talk to you. I hope you enjoyed it. If you have questions, we can either take them now or over lunch probably because I'm standing between you and lunch now. So thank you very much. I hope you enjoyed it. I certainly did and I hope to have good discussions going forward. Thank you. So yes, we do not have too much time for questions but if you have one or two. I have one. What's for lunch? What is for lunch? I don't know. So maybe there is no question we can go to lunch. Thank you. Thank you Elena. Sorry, we miss also two presentation for the first session of the afternoon. So if there is some speaker come to join us.