 Hi, everyone. I'm Matteo Carlinini, Director of Software Technology Management at ARM. My colleagues Shabu and I are also Chairman of the Board of the TrustedFewment.org project. And today, we're going to give you an overview on what the project is and how we are helping out the industry building more secure firmware on all ARM devices in a completely open and collaborative way. So the first slide is really about security vulnerabilities which made the news in the last couple of years. You might recognize some of those, like the most popular in the middle. But the key point is that these security vulnerabilities are affecting all the devices we are interacting with in every single day of our lives. They affect IoT devices, connected cameras, smartphones, automotive systems, laptop servers, everything really. Now, this slide is very generic. It talks about general software vulnerabilities, not necessarily only regarding firmware. So let's have a look instead, specifically at the firmware vulnerabilities as identified and extracted by the NIST, the National Vulnerability Database. And you will see that the trend in the last five to ten years is that firmware is increasingly becoming the preferred target for attacks in every system. So there is a very simple explanation for that. And that is the firmware is the most privileged, the highest privileged software, piece of software that runs on every device. So it has more privileges than a hypervisor and more privileges than an operating system or any possible applications that runs on the device. Which means that a vulnerability in the firmware can bypass or overcome security hardening or features targeting security that are implemented in hypervisor or operating system. So it can also weaken a lot of features like secure boot or measure boot. And the real reason then is that if you own the firmware on a device, you really own the device. You own all the system, all the resources on that device. And that is why it's so appealing for attackers, as you can see from the graph. And 2020 is on the same trend of the previous years. But as we always say, there is hope, there is always hope. And we strongly believe that hope, in this case, passes through collaboration. Collaboration is key for building security in firmware for a number of reasons. So the first one is that software vulnerabilities and firmware vulnerabilities specifically are very complex problems to solve. So think about Spectra, for example. So hands up how many of you have understood properly the Spectra attack. And then how many have understood it by reading it at the first time. So it really requires technical experts, security experts in the field to openly collaborate around finding proper solutions for these vulnerabilities. And then if you look at the right hand side of the slide, this is just a snapshot of all the industry players in the IoT market in 2019. So it's a large amount of players, a large amount of companies. Which clearly means that security fixes and security within the industry has to be scalable. So it's a security by scale problem. All the mitigations, vulnerabilities, fixes of vulnerabilities that we find needs to be applicable to all the single partners and needs to be deployable by all of them. And if we find a way to solve these security problems which are so complex in a unique place, we are really achieving security by scale. We are solving the security problems once and for all, for all the members and all the industry that then will have to deploy and upload all their devices. So complexity, security by scale, two main key pillars. And all of them passes through collaboration, getting the right minds together to find the proper fixes in a scalable way. And this is the reason why, couple of years ago, six companies came together and decided that it was the right time to form the TrustedFirmware.org project, which at the time was based on the two main projects donated by ARM, TrustedFirmware A for the A class processors and TrustedFirmware M for the M class processors. This was the shape of the project at the beginning, two years ago, six founding members, two main projects. But shortly after, we were joined in 2019 by two other big companies, and by Yopti, which was donated by Linaro as a reference implementation of a Trusted Execution environment and moved into the governance of TrustedFirmware.org. Finally, this year, other two big companies joined the project, and also two more projects that you can see down there, and Beth TLS and Hapnium. And we will elaborate a bit more on these projects in the next slides. So you can see above the current roster of all the projects which are forming the TrustedFirmware.org open governance community project as of today. And so TrustedFirmware, as I said, is an open governance community project, which provides the reference open source implementation of all the secure software running on ARM processors across all the different market segments. For A-profile, so processors implementing the A-profile architecture and the M-profile architecture. Membership of the project is open to everyone. There are two main bodies which govern the project in its lifetime. On the left-hand side, the board of project members, just comprised by these 10 companies, part of the project. So the board typically decides on the investment and strategical direction of the project. While on the other side, the technical steering committee, which is formed by technical experts, by the company members and by the ecosystem, which decides on the technical direction of the project. So as we said, TrustedFirmware applies to all market segments. Let me rate the rate on that. So from low power, resource constrained devices like IoT or wearables, up to smartphones and connected devices, automotive systems, laptop and clamshells, clearly covers all the embedded space, including the edge and edge computing space, finally up to server general purpose servers or cloud deployments as well. All of them have devices which implements TrustedFirmware as a basis for their entire software stack. So having such a wide variety of markets to address, we realize at a certain point this year that we needed a more robust and organized and centralized security vulnerability and security incident process. And that's why we defined the new process, which is described in the page linked above. We have one single place of reporting now, which is the mail alias in bold, they are in the middle. And we have also identified the need clearly for a coordinated disclosure process of security vulnerabilities. And we aim to coordinate that with what we define trusted stakeholders and especially sensitive stakeholders. These definitions are described in the registration page and companies are more than welcome to get in touch with our project and with the mail alias is listed in that page for having more information. We also have security mail aliases for every single project, which comprises TrustedFirmware.org, TFA, TFM, and BATLS, and so on. But I really encourage to go through the centralized space and the security at mail alias in the middle, if you are in doubt, that's the really new centralized security place in which all the experts will look at the advisory and get in touch with the reporter for fixing properly the vulnerability. Now let's have a closer look at the first project of the family, TrustedFirmware A, and then we will go through all the others one by one. So TrustedFirmware A is the older project in the roster. TrustedFirmware A was really born seven years ago in 2013 under the name of ARM TrustedFirmware. It was an ARM project which was donated in the open through GitHub. It has always been released under a BSD3 closed license, so permissive license, and it's now accepting all the contributions under VCO. So no need for sign any contribution agreement. So it's a well-established project, alive for seven years with a lot of major releases. We are now approaching the release of 2.4, which will happen in few weeks from now. There are already announcements on the dedicated mailing list. And what it provides, it provides the reference implementation and the reference boot flow, TrustedBootFlow, for all the cores implementing the A-profile architecture. Cores both running at AR-64 or AR-32, and there is also support for the legacy V7A cores and systems. The diagram shows what really comprises TrustedFirmware A, so the EL3 runtime portion of the firmware, and also the EL3 and the transient SEL1 boot time portion. If you want to know more about the inner architecture and all the list of features for TrustedFirmware A, I would encourage you to look at the ELC presentation from a few months ago. Two team members gave a varied aura description of all the features of TFA, and you can retrieve the video from the link below. So, have a look a bit, instead of the statistics, more high level of TrustedFirmware A in terms of contribution, because we spoke a lot about collaboration. So how does the collaboration look like for TFA over this period of time of seven years? Well, when we started the project seven years ago, ARM TrustedFirmware clearly started with zero contributions from partners. In the other commits, all the code was developed by ARM engineers. Then, as the project became more and more popular, a few contributions started to come in, but at the time, we still had, ARM still had in place a contribution agreement to be signed with every contribution company. And we realized a little bit later in 2016 that that was really a barrier for people to contribute more openly. So we decided to get rid of the contribution agreement and just accept every contribution under the terms of the DCO. And as you can see from the graph, that immediately boosted the contributions from partners and ecosystem. Contribution continued up to late 2018, well early 2018 when we announced TrustedFirmware.org, and then autumn 2018 when we launched the project. And then another boost of contributions that continues nowadays with the introduction also of Hathnium, elaborate a bit more on Hathnium in the next couple of slides. And you can see the increasing trend continues. It just doesn't stop. We have, as of today, more than 45 partner platforms supported upstream from more than 20 vendors, different vendors, not ARM platforms. We have done 14 open source releases, including the upcoming 2.4. And in 2020, we also pointed new containers for both EFA and Hathnium. And half of these containers come from the community. These are not ARM employees, half of them come from partners and ecosystem players. So it's a history of huge success and huge collaboration. You can see an increase of 600% of contributions in the last four years, and more than double the contributions also in the last couple of years. Really a great story of collaboration. TrustedFirmware A comes also with a test project, which is equally released in open source, and it can be extended from our partner so the test cases can be extended as well. The project is called TFA tests, and it provides a strong basis for validating the interfaces from the normal world without the need of running a proper fully fledged high-level operating system. It doesn't really have an 100% coverage, but still it provides a strong foundation for testing all the interfaces for the interfaces listed below, for the specification listed below, including the most recent one, which is the firmware framework for the A-class devices, which I'm going to talk to about that in a second. As I said, this is all open source, same license and same contribution agreement as the main project, and partners as they develop and upstream features can also develop and upstream the test cases for those features as well. So let's talk a bit about Hathnium. What is Hathnium? Hathnium originally is a project started by Google that was donated earlier this year in April 2020 to the TrustedFirmware.org community project. Hathnium comes as a reference implementation of the secure partition manager for the ARM A.4 Securiel 2 virtualization extension. And it fully implements the firmware framework for A-class, the FFA specification, which I was talking about. It's been donated and it's been contributed and licensed under the terms of PSD-free clause, as all the rest of the projects under the TrustedFirmware umbrella. It comes with a very minimal cut base and a reduced attack surface. It enforces the principle of least privilege and it really threatens the defense in depth of all the software running in TrustedZone. And one of the main news cases is that it enables the isolation of different secure partitions which can implement different services or even different Trusted Execution environments in TrustedZone. Isolation in the sense that these partitions will be isolated one another. We have a supporting quote from the Android security team, which we captured during the launch of Hathnium within TrustedFirmware.org earlier this year. And looking at the architectural diagram of what Hathnium and TrustedFirmware aims to achieve on A.4 enabled platforms. So you can see the blue boxes, TFA running at EL3 and Hathnium running at SPM in Securiel2, achieve the isolation of different secure partitions running in the secure world on top of Hathnium. These partitions, as I said before, are isolated one another and they have a limited view of the system resources which is controlled by the underlying Hathnium SPM. But the important thing to realize is that the combination of FFA, which is the specification that defines the interfaces at the boundary level of each component. So a combination of FFA and Securiel2, with its reference implementation, achieve an increased security. Because now the underlying firmware EL3 plus Securiel2 is protected from compromised software running within the secure partitions. So if there is a malicious code which takes control of one secure partition, that code is no more able to compromise the highest privilege firmware. So it's no more able to own the entire device. And therefore, also the normal world is protected from compromised software running in these partitions. So we really achieve a higher level of security and defense in depth by implementing Securiel2 and the isolation that it allows. There are other two pillars of the combination of FFA and Securiel2. One is around the standardization of the interfaces, because clearly if all the components implement the FFA specification, one partner can deploy one secure service, either in the normal world as a VM in the normal world running on a typical hypervisor, and easily port this VM in the secure world running on top of Halfnium. So we achieve portability through standardization of the interfaces. But we also achieve de-fragmentation of the secure software space of all the software running behind TransZone, especially highest privilege software. Because the blue boxes are then delivered through TrustedFirmware.org, EL3 TFA, Securiel2 Halfnium SPM, and also a reference OPT TrustedOS and its Trusted application. With de-fragmentation, we achieve the transparency of the firmware which is running on the device. So we can really tell from which code base and from which release a firmware has been derived from. And that is all the certification and audit process of these generic firmware pieces. Eventually allowing our partners to reduce their time to market and their maintenance cost for their most secure software piece on the device. And now it's time for me to hand over to my colleague Shabu, which we'll talk to you about the evolution of OPT under the umbrella of TrustedFirmware.org, and then we'll talk about the other projects part of the TrustedFirmware family. OPT stands for Open Portable Trusted Execution Environment. It is used to create a Trusted Execution Environment on Cortex-A devices, leveraging the ARM TransZone technology. It works as a companion to the Linux kernel running on the normal world along with applications. OPT provides global platform compliant internal APIs which the Trusted applications running on top of OPT can make use of. It also provides the global platform client APIs which allows normal world Linux based applications to communicate to the Trusted applications. The project was originally launched by ST back in 2013 and it's in 2019 the project was moved to TrustedFirmware Community Project Governments. One of the work that the project has been doing more recently is around providing the platform security architecture root of trust for Cortex-A devices. PSA is a program that kick-started around three years back to provide better security to platforms by providing architectural specifications for hardware and for firmware that will aid vendors to create secure platforms. And as part of that program, there is the associated open source implementation which is where OPT comes into picture. As part of the PSA program, PSA has defined a set of PSA functional APIs that allows applications to easily use the security that is provided by the underlying hardware platform without having to of course understand the complexities involved in the security of the platform. As shown in this implementation, we have been working on providing implementations against those PSA functional APIs for basically three functionalities, cryptography, secure storage and attestation. By allowing those to run a secure partitions in secure EO0 above OPT, this allows Linux-based applications to make use of these secure services by calling these functional APIs which gets wrapped using the firmware framework A transport layer. It reaches the OPT layer which then using the secure partition manager gets dispatched to the appropriate secure partitions thereby availing the secure services that the application requires. This adopting this implementation on Cortex-A devices allows platforms to meet the requirements for PSA certification and thereby certify their platforms. Now let's look at one of the other trusted firmware projects, trusted firmware M. Again, this is also a reference implementation that was born out of the platform security architecture program in terms of providing a high quality open source reference implementation. Trusted firmware M provides a secure processing environment for the ARM Cortex-M CPUs. It especially leverages the trust zone technology to bring about isolation between the non-secure processing environment and the secure processing environment. It consists of a secure boot which allows to authenticate runtime images on the platform. For TFM runtime there is the TFM core component and the secure partitions. The TFM core is responsible for partition management which means it makes use of trust zone and MPUs to create isolation between the non-secure and secure processing environments and within the secure processing environment using secure MPUs it creates isolation between the different components as well. Then there is the secure partitions which you can see is the secure endpoint of the system which is sandboxed and is accessible through user authentication mechanisms. These secure partitions normally would have related secure functionality. A secure partition can be a crypto secure partition and the secure partition can be a storage secure partition. All these things are merged together in a single sandbox secure partition and applications are then able to call the secure partitions via the calling mechanism enabled by TFM core. TFM has been in development for the last two or so years and today we have got TFM one by one which is the latest release version which allows platforms to be PSE level one or level two certified and also achieve the PSE functional API certification. Quickly going through the functionality that TFM supports today it supports the PSE level one and level two isolation using trust zone and the secure MPUs which creates isolation between non-secure and secure world and between the PSE root of trust which is the most trusted portion on your platform and the application root of trust. It supports multiple secure services which most of the IoT applications can make use of in order to achieve security in their use cases. So the secure services are the protected storage, the internal trusted storage both used to store secrets whether it's use case specific data or to store keys, certificates, etc. securely in the normal time memory. Then the cryptographic service which allows you to do the cryptographic operations whether it's for establishing a TLS connection or for secure debug, etc. And an attestation service which allows the platforms to prove its identity to a remote entity like a cloud service provider. The crucial attestation service we use the entity attestation token defined by IETF as a format to collect platform specific data, sign it using the attestation key pair you need to the device and then send it on to a relying party who can verify and then create trust on the platform itself. Today TFM is supported on a wide variety of silicon platforms. Here are a few, the NXP LPC platform, STS, STM32L5, Cypress Psoc64, and the Rene CSI6M4. TFM is also integrated with some of the more popular open source real time operating system. So today you can see upstream integration of TFM in embedded OS, free R2S and Sapphire for certain platforms. Here is a quick, very quick look at the free R2S integration that we've done recently in cooperation with Amazon. So in the free R2S kernel repository the link is given here. You will see an example of how TFM is integrated to free R2S on one of the ARM reference platforms. In the Amazon free R2S repository, there is a PSA API shim layer which allows the PKCS APIs that Amazon free R2S uses as to store certificates and for KLS client authentication to in turn use the PSA API supported in TFM wireless shim layer. And this is also enabled in certain platforms. Again, this all allows free R2S and TFM enabled platforms to leverage the underlying security provided by the hardware. In one of the more recent work that we have been doing in the TFM project is around profile, considering the huge variety in the IoT world in terms of complexity of the device, the device capability in terms of CPU performance and memory. You will see a lot of these devices would exam enabled will have different device configuration and use cases, whether it's a small home base, smart bulb, smart thermometer moving on in terms of complexity, whether it's a smart meter, an educate way or a tiny robot. All of these will have different security requirements. So TFM is starting to provide pre configured bills, which will have different security capabilities more aligned with these use cases. And these profiles are also aligned to the PSA certification scheme, which means as per your use case you can pick up one of the TFM profiles in handset to add any more functionality and then you will also be able to certify your platform using the PSA scheme. Now let's look at the last TrustedFirmware.org community project. I would say it's one of the most widely adopted TrustedFirmware projects as well. It came to TrustedFirmware.org from earlier this year. What it provides is easy to use TLS library and also supports X509 certificates. As I said, it's very widely used in a wide variety of segments, especially in the embedded space. Again, it's distributed using a Bashi2 license. And although it has been well adopted and it's got a huge user base, previously it had challenges around getting contributions into the project, reviewing it by the maintenance, etc. So the move from ARM to TrustedFirmware.org is with the sole aim of making MBTLS a more vibrant community project with ARM very much still heavily invested in this project with most of the maintenance still coming from ARM. I'd also like to call out the PSA Crypto efforts that has been going on under the MBTLS umbrella. Here the aim is as part of the platform security architecture program to provide a world-class PSA Crypto library that contains all the required Cypher algorithms that are exposed using the PSA defined PSA Crypto APIs that can be used inside a trusted execution environment. It can be used by other security related use cases like secure board, secure debug, etc. It's very much advanced in terms of development, in terms of supporting all these crypto APIs. Of course, it has been derived from the MBTLS project. So MBTLS project is being separated out into two libraries, the MBTLS bit which has all the TLS aspects in the traditional MBTLS project and the PSA Crypto library which basically has all the Cypher's that are getting exposed through the PSA Crypto APIs and MBTLS over a period of time would move to fully using these PSA Crypto APIs as well. And we have been also trying to define a PSA Crypto driver interface as part of this program which would allow PSA Crypto implementation to be integrated with secure elements and accelerators by having vendor drivers that has returned against the specification. So this will allow us a platform which has got secure elements or accelerators will get invoked by the PSA Crypto APIs instead of being executed at the software library level. So we have very quickly looked at some of the trusted firmware community projects starting with trusted firmware A, hafnium, opti, trusted firmware M and finally MBTLS and PSA Crypto. One common theme across all these projects is collaborating to build world-class security solutions. There has been many initiatives since tf.org was formed in terms of bringing this collaboration to the next level. OpenCI being one of them. What this allows is any patch that gets submitted into one of the constraint projects results in a build job that builds the different configuration of the constraint projects and then it gets tested using the linear test system on a variety of platforms that the project supports. And this is all openly visible to the developers who are submitting their jobs. So what this gives is an easy way for the developer community to work on patches, validate whether they are introducing any regressions. And it makes the life of the maintenance a lot easier because they can then easily have the conversation with the contributor about what might be failing and what the developer needs to fix. This is an ongoing effort. So today we have got support for M, A and hafnium in the open test system and there are more features like static analysis models and more platforms that's getting added in this openCI and boot farm. Again, continuing on the collaboration theme, we do have biweekly open for tech forums for many of the projects which has been up and running for many months now which brings together the relevant developer communities of those projects discussing new design ideas and implementation details. We had a workshop last year in Lyon for President of America M. Considering the current pandemic situation, we can't hold such a session physically so we are going virtual with an MBTI list workshop being planned for November the 3rd. I would encourage all of you to attend this half day event where the aim is to bring about more collaboration in this great MBTI list project, talk about how we move forward in terms of improving the speed of reviews, getting more features into the project, etc. A sneak peek preview into the future direction of the project, etc. As we come to the end of the presentation, I would like to talk about the holistic approach the community project is taking towards collaboration and it happens at all level starting from a very vibrant now for almost all the trusted from their projects where any new design ideas are openly discussed issues are being brought up by the developer communities and by the user base. Then as I said, there are biweekly tech forums, workshops being held once a year, all the code is openly available. It's hosted in Git or in GitHub. There are open reviews happening in GitHub or in Garrett. So the development flow happens totally out in the public. Anyone can review the patches. Then finally, with the open CI this enables all the work to be openly tested. That's being able to maintain the high quality of these code bases, but at the same time, allowing collaboration across a wide. Number of developers as well. To conclude, I would like to say that technological innovation is hitting all aspects of our life, whether it's through autonomous machines, IoT devices, cloud computing platforms or mobile forms. But this comes a lot of challenges to the cyber security world. And if you look at some of the top predictions in the 2020 cyber security reports, one of the recurrent three theme is of course the increasing complexity of some of these security issues and the ever increasing skills gap to address these issues. So it's quite important that as we continue our journey towards a trillion devices in the next few years to have a collaborative approach to build security software that will power the next trillion devices. Thank you very much. So I encourage you to go and visit our homepage trust informer.org where you'll find a lot of useful information around all these six projects. Please do subscribe to the meaning list and the check forums. And if you have any questions, please do email us at enquiries at trust informer.org. Thank you very much.