 I'm Alex and I will be talking about Component, which is our vision of the secure mobile platform. But why do we need this anyways? It's always a bit hard to keep up with all the security incidents, incidents that happen and originally I plan to use as a motivating example. Something from last year where Google keep tracking your location and sending it to its servers, even though you had location disabled. But then last week I came across this news from a German newspaper, which said that the German Federal Police is able to monitor your messaging, your WhatsApp traffic, for example, or any other messenger that matter. And how do they do that? Are they able to break the crypto? As you may or may not know, the encrypted and current messengers is pretty strong and the protocols have verified partly and so on. No, they do not have broken the crypto or anything. They get your messages before they get encrypted and after they have been decrypted for the other way. And that's a problem with your platform actually. So they install a trojan horse on your mobile phone and get the messages even though you're doing encryption. Sadly, that's a problem and we're going to talk what our ideas are, what to do about this. So first, I will tell you a bit about the challenges we have and why these smartphones are so problematic when it comes to security and strong encryption. Then we talk about our objectives in the project and I will tell you what we are using, what technologies we are using, what the architecture of a trusted system should look like. And that's another interesting question to also get that trojan horse problem under control. How can we implement a high assurance, a trust worthy platform so it really, that's what we want to do and cannot be hacked. And I will tell a bit about how our platform is looking like or what we plan for the future. And of course, what the current state is and what we do in the future. So there are actually a couple of problematic, three big issues in smartphone platforms. One thing is at the hardware level and this is really nasty as the isolation between the radio networks you're using, be that Wi-Fi, Bluetooth or even the radio network, they are not very well isolated. And so it is possible that an attacker that's on the radio network that has, for example, set up a fake base station or set up a fake hotspot, he can bring your device under control and subsequently actually do what the police and also malicious hackers are doing, get access to your data. There are a couple and all of these examples are from the last year. There are a couple of incidents that demonstrate clearly that this is an issue. For example, the Broad Pone weakness last year where someone, which allowed an attacker to get your application process under control from a Wi-Fi network. So without any interaction, no clicking some malicious link or open an email, you're not supposed to open. It's really like a passive attack and then your phone gets hacked. Another example is the, it's a blue-born, something comparable to this, but over Bluetooth you can't even have your Bluetooth disabled and your device not in discoverable mode doesn't matter. So unless you have patches for this, someone could take control over your device without your interaction. And lastly, that's also a hardware issue. The basement processor, which is the one that's actually talking to the radio network, has had the same issues in the past. And I also was something with Huawei chipsets, I believe, in the last year, which is comparable and could be exploited from the radio network. That's obviously not good, but there's more to come. You may have heard of the stage fright vulnerability. That was something that came up in July 2015. Millions of devices were affected by that and it was as simple as sending you some media content like a video stream and then allow and exploit. It would be able to exploit the media server, which is the central thing, that does all the media decoding in Android and take control over your device because this has rather high privileges. I did some calculations, I got the figures because I was wondering, is that resolved meanwhile? That was 2015 when the stage fright was in the media and was a hot topic, but since then, as you can see in the graphics, the number of critical bugs actually has not really declined. Sometimes it's only a handful or one or two bugs, but sometimes we also have 10 or 20 bugs per month that affect this multimedia subsystem and can potentially be used to get your system under control. This is another big issue and all by sending you something like a picture or video, something that you probably get every day. There are these third class of privacy issues, privacy leaks. The Android platform is not really built for keeping your data private because private information is considered the oil of the new digital age, so people want to get your data, of course, though. Several incidents, it's all from the last year, like the one I mentioned, Google was tracking you even though you had the location service disabled. There was, for example, that thing with that keyboard that would send the suggestions you had in your address book into the cloud, and then that was a bug, but then this could end up in a different person's keyboard and you suddenly had contact information of someone else as a suggestion in your keyboard. So apparently the current platforms do not do very well when it comes to keeping your information really private. So the question is, and I have answered that for myself, would you really do your banking application with that kind of platform given that it's rather fragile and there are so big attack surfaces? So we want to do something about that with the component project. Firstly, of course, it's open source, you would have expected that, and it's going to be a platform for mobile devices. And the goal is to run unmodified Android apps on a completely new operating system, but with high trustworthiness, so eliminating all the issues or hopefully most of the issues that I've just mentioned. Firstly, we want to prevent, we want to protect applications from getting compromised, we want to confine applications, so they cannot, a bug in one application cannot influence another application or the whole system. And thirdly, the user should remain in control so that no one can decide to, for example, feed the location information into the cloud without the user really knowing that or even being able to switch that off. But why are current systems so problematic, actually? Why do we see all these issues? So what we see here is a typical overview of a monolithic system, and the problem here is that we have large monolithic personal portions like the Linux kernel, and they implement complex features. And so when one, for example, uses that media framework that we have here, or the kernel, this belongs to its trusted computing base. That means all that needs to be correct for the application to work correctly. And if there's a bug in any of these millions of lines of codes, then this can also affect other applications if they share one of these big monolithic blocks. And the consequences is that the probability that we have some bug that can be exploited and has an impact on other applications is rather high because the trusted computing base is so high and the chance for critical errors. The issue now is we cannot really avoid that complexity because media decoding is a complex process, networking is a complex process, but we can manage it cleverly. And for this we use the Genote OS framework, which is another open source project, and it has the nice property that it has a recursive system structure which facilitates a small trusted computing base. So if you see the tree here, there's a root, which is the parent of all the other processes, as you might know it, and this parent has control over all its child processes. This will typically be a microcode, which only does resource control in separation in the system and the parent needs to create everything out of its own resources and has the full control so it can also again remove the resources. And so we can start building a recursive system structure where every child also makes up such a tree and again has control about the subtrees. This allows for a small trusted computing basis. If you see that orange application here, the trusted computing base is only what's upwards in the tree and maybe services that are used. And we can even reduce further the trusted computing base so the Cray application for example could implement some very complex functionality like a whole network stack or a driver. But if we have another application that's a trusted wrapper, for example, does encryption transparently, then we do not need to trust that network stack because packets are encrypted before they are sent out. And so this is outside of our trusted computing base. Genote supports a number of interfaces for legacy apps also. For example, a virtual machine environment where it can run complete PC operating systems, it can run QT apps, POSIX apps also and there's a device driver environment for reusing existing Linux device drivers. If you want to know more about this, the micro-colonel death rooms where the creators of Genote are around. So now when we have these components that make up the trusted computing base, there's a second question. How do we make sure they do the right thing? For this, we use Spark, which is another open-source technology. This is a language that's made for building high-integrity applications. It has a strong type system which helps a lot. It's designed, the language is designed for avoiding errors. And what's in particular nice, it has formal contracts so you can define invariance and pre-imposed conditions. I have a Spark example program on the right. And as you can see, there's an analysis tool that checks these invariance. And in line 11, for example, you see that something is wrong. This function is supposed to calculate the absolute number of something that's passed in there, integer x is passed in. And what we do is if x is greater than zero, we return it. If x is below zero, then we return minus x. So that's something that probably most of you would think is a correct absolute function that calculates an absolute value. But if you run the Spark tools, they say, okay, here's something wrong, because if you put in that minus 2 billion something number, then this is an error. And the reason is that in two complements representation, we just, the range of negative numbers is higher than the range of positive numbers. So we cannot represent such a large positive number, and that the tools catch. And you can, as they're in the command, as the command suggests, if we say, okay, x must not be that small. We can add a precondition that then prevents us from putting so small values into that function. And so we can, the tools catch that issue. You're flexible in what, how deep the verification goes. You can only do data flow analysis and catch issues where uninitialized variables are used and so on. And you can go down to really prove, to really prove the absence of runtime errors. So you get no exceptions. And to do not do out of area indexes and such kind of things. If you want to learn more about Spark, there's the Adaf room where there will also be talks on Spark. Okay, let's put that together. What do we want to do with these technologies? This is an example that we have built to get rid of these hardware and network related issues. So I told you that an attacker can attack your phone via the radio network because the baseband processor may have a flaw and then the isolation between baseband and application processor is not strong, partly per shared memory. And so once in the baseband processor, also the application processor can be accessed. And what we have done is using the G-note framework. You don't see all the components here. Right now it's abstracted away. We have the G-note framework. It's running on a microchannel called NOVA. And on top of that, we built a Spark component which is denoted as firewall here. And what it does, it's connected to a virtual machine running Android, running a version of Android. And all the communication between that Android and a second device, which is also running Android, which is running a standard Android phone distribution, that does actually implement the communication with the radio. That's how it looks like. So really on the right side there's the G-note base system. You have the virtualized Android on the right side, can really interact with it, and it's connected via USB with the phone that's actually only running the baseband software. And in between, this is a lock window, what you're seeing, all the messages between baseband and application processor get filtered and validated in a Spark component so that if someone would send a message that exploits, for example, a buffer overflow, this would get mitigated, this message would just get dropped so that on the right side, the virtualized Android is protected from any attack from the left side. And of course, as they're connected by USB, there's no direct connection anyways. Okay. Another thing that I was mentioning is that you have little control over what's going on in your system. Someone can, an attacker could just take, for example, an app that's sending all your contact information to the internet. We want to do something about that too while using resource filters. That is, the app system in Android typically is very cost-grade, so it's an all-or-nothing thing. You grant an app a permission to get your contacts and it can get all the contacts. If you don't grant that permission, then it may malfunction or crash completely. And when it has the permission, it can do actually everything that's associated with that permission. And when you think back to that Spark component we built for the baseband firewall, you can think of the same concept for Android applications and the permission. So our vision is to put a filter in between the Android app and the rest of the system and so it's possible to precisely track what the applications are doing and then enforce a user policy that's far more powerful than what's possible on Android right now. Okay, so our general goal in the end and we are only on the way right now is in contrast to what you get suggested, typically you don't have to update very often because the security is enforced by trusted components where we have proven that they do the right thing. You may also in the future or the platform click on any link that you like because it cannot do harm to the overall system. And of course you should be able in our vision to install any arbitrary app from any app store without any problems. Of course using cellular Wi-Fi and Bluetooth networks should not be a security issue as it is today. And of course I don't know whether you have an antivirus but it shouldn't be necessary and it shouldn't be there because it increases your tech service anyway. And of course the vision is that you should be able to do sensitive tasks like banking or controlling the industrial system on the platform. Right now we have Android, as I said, only in a virtual environment, so a complete Android. It's also not running on a phone yet. The system is running on a PC right now but the vision is to really bring it on a phone and to port the Android runtime which we are currently working on onto the Geno platform directly so we can run unmodified Android apps without all the rest of the Android and with tight control through trusted components. In the future for this we need to create such a bridge between these two worlds, the Android world, the Android runtime and the Geno system and of course we want to build more of these protocol wrappers that we have done for the basement processors so we can also have trusted wrappers for Bluetooth Wi-Fi and so on. And of course we need to bring this on a real telephone so it's actually usable on a device. Everything we built is open source, as I mentioned, under AGPL. We develop it publicly so if you want to get in touch or try it out, you can do this on GitHub. Yeah, and if you want to get in touch with us or have questions or suggestions then send us an email. Thank you, are there any questions? Yeah. We are going to solve the problem of the policy data. Yeah, so the question, if I get this right, the question was if we can do more fine-grained policies than the Android permission system and for example deliver random data instead of real contacts, how would we solve the problem of the user making the right decisions? Was that the question? We do not have a solution there. We have other systems like the exposed framework which try to solve that, but honestly currently we are on how to really do the technical control of these things level and that would be an open question actually. One could think that an application can only read out contacts that it has written in there itself and they get tagged somehow, but we don't have a full concept of that so far.