Maemo 6 Platform Security
Reshetova, Elena
The presentation will cover the Maemo Platform Security Architecture in more details, providing a deeper technical view on its components and their interaction. The purpose of the Platform Security in the Maemo 6 platform is to protect the owner of a Maemo-powered device from getting her personal, private data and passwords from being stolen and used for malicious purposes, to prevent a malware from misusing a device and incurring costs on user, to prevent a user from accidentally breaking the device and to make the platform meet the requirements set by such third party software that requires a safe execution environment. The presentation will cover the Maemo Platform Security Architecture in more details, providing a deeper technical view on its components and their interaction.
 I think it's already a bit after two. So good afternoon to everybody and I hope everybody had a nice lunch. And this I think the first session for security, the first talk of the security session. And my name is Elena Rechitova and I'm coming from Nokia My Amour platform. And I don't know if many of you are familiar with this N900 device. So this is a device which runs open source development platform. The name is My Amour. I guess there is even a competition where you can get some of these devices today. And I'm working for platform security in My Amour and the new platform security which is coming for My Amour 6 release. And this presentation is supposed to give a short review about My Amour platform security. And let's see how much time we have. I would like also to leave the time for questions. So here is a short outline. So first of all, I will just briefly talk about what is platform security or to be sure that we speak the same language when we say this term platform security. Then we will take a look on our different two different device modes of operation for My Amour 6 device. And I will say the reasons for these two different modes. And also during the boot, we will take a look on a boot process to understand how you can get these two different modes loaded. We will take a look on access control, one of the primary things in security framework. And we will take a look on different things related to access control. Also integrity protection. And we will finish with security of inter-process communication. So what is platform security? So here is in the slide it says that it's set of mechanisms and techniques which are used to protect the entire software platform. So let's imagine we will try to build a house which called platform security. So what are the bricks here? So what are the mechanisms and techniques here? So in the bottom of our house, there is a big brick called hardware enablers. So this is actually a very important piece for whole platform security. So these hardware enablers are needed in order to guarantee that software, the security software which runs on top of it, it's actually really secured from the software and possible attacks. When there is free middle bricks which here stand for integrity protection, access control and privacy protection. So integrity is to, we need to protect integrity in this case. It's integrity of our binaries, executables, also configuration data files. So everything which we would like to be sure that it was not modified during the lifetime of a device. Of course, authorized modification are allowed but non-authorized or not. And when the access control very, a known thing in security frameworks. So who is allowed to access what and why and so on. And the last one is privacy protection. So here it mostly means the encryption of user data or your private data for reasons that you would like to keep them secret and not accessible for anything else. Then a set of for example limited programs. And on the side of all this bricks of our house, there is a key management. So key management is needed on all of these levels. So that's why it stands aside. And on the top of house there is a roof called here security policies. So this is the control point of all platform security. So security policy defines how all these mechanisms are working and what is the needed security level. So this is really just a couple of words to explain what is platform security. And so now let's move to the interesting part. Here is a slide called device modes. So many people are afraid. So my more platform is an open source development platform. And many people are afraid that now when I'm starting to speak about platform security, it means okay, the platform will be closed. So when security, there is like a common understanding when security comes, the platform goes closed. So that's why I have this first slide already explaining you that it's not going to be the first. And we will take a look on the first mode of device operation. There is no particular name for this mode. I don't know. People will probably come up with interesting names after. But these mode of device operation is the same mode as we used to have on previous memory releases. So for example, this device runs MAM5 release. So you can do whenever you want with a device, you can compile, build your own kernel. You can run your own kernel. You can make any level platform development. So whenever you were able to do before, you can still do. And there is a special mode even for you to do it. So the only thing that you need, you would need to put your device, MIMO6 device to this mode and then you can do things that you would like to do. There is a second mode, which is going to be for MIMO6. And the reason for introducing this mode is that we would like to have to even extend even more our developer offering. So we know that there are developers who would like to make a bit of profit from their own very good software. And we would like to give a choice to them to do it. So it doesn't mean that when it says here copy protection, it doesn't mean that all software needs to be copy protection and it will be DRM protected. It's just a choice for you. So if you would like to have the possibility to own money on this platform, you can use the copy protection. You can put your software in the DRM. But if you don't want to do it, there's nobody who will force you to do it. So you can still distribute open software and it's more than welcomed. And there will be also a way to move between these two modes. And this can be done with a booting process and next slide will show how actually you can reach each of these modes. So the boot process is very high level. So not many details will start from a boot ROM which will first check integrity of the loader. And if integrity of the loader is okay, the loader can continue. So the loader starts to run and it will check the integrity of software image. And if it's software image is considered to be Nokia sign software image, then this second mode which I showed on the previous slide. So the mode which provides you DRM protection and access to application store which you know it called OV store. So you can load this mode because the kernel is fine, the software image is fine and it's Nokia sign software image. So let's now take a look on what happens when some of these components are not fine. So if the loader is, if integrity of the loader failed, then we can't allow this because we can't allow entrusted loader. So the device goes to reset so they're not allowing the change of the loader. But if integrity of software image failed, so there is still one question to be asked here. So if this device is SIM locked, so SIM locked here means that you for example buy the device from operator, usually it's less price, but you have to use it with the same, I don't know, I never tried to do it. So you probably have to use it for one year with some SIM card and it's locked to the SIM card. So if the device is SIM locked, then in picture it says that the other image is not allowed, but it's not up to us. So it depends on operator, on your contract with operator, maybe some local legislation in the country. So we really don't have any stand on it. So it's up to operator, but it's also up to you not to buy these devices from the operator. And just to mention this part, and then if device is not SIM locked, then we will allow to boot any unsigned kernel, any unsigned software image. There is only one step which will happen in between here with books saying restrict security functionality. So here, this step we need in order to protect things like for example DRM keys, because these keys can't be compromised and we need to disable these keys. And there are also a couple of small things which happened here, but after these things are done, you can load pretty much any, so you can load any unsigned software image. So the one you did and the one you compiled, so nothing prevents you to do it. So this is again high level with boot process. So let's move to access control part now. And here we got actually quite many questions already that there are many existing access control solutions in whole operating systems. And the question obviously of which we were asked is why are we doing our own access control here? And here's a slide which presents a bit of our reasoning why we decided to go this way. And first let's start what we had before. So what does our, what do the previous memory devices have? So the only thing we actually had it was the classical Unix access control model, which is a very user-centric model. So it was the threat, the threat model at the time when it was developed was there was number of users who were using the same PC and the goal was to separate data of these users with one, let's say, some bad user can't read your email, so can't read your private files. So this was a threat model when this classical Unix access control was created. And it was discretionary access control, so user and owner of the file could change the ownership of the file. And later the situation, we were trying to change this, let's say, extend the classical Unix access control by reducing, for example, Pozik's capabilities. And it was, I think, a very good idea, but they're not really in use now. So for example, root by default has all of them and others, users none. So kind of the concept is there, but it's not really used. And then our criteria, so my demo devices are mostly one user devices. So there's no actually need to protect one user from another user. So what, in the threat model now is that we would like to protect data between the processes because there's many applications that user installs. And the typical user, it doesn't really understand, and the program may look very nice and things that can be malicious. So users don't understand it. They may install malicious programs and they may try to steal the data and do other harmful things. So we would like to have access control, which is in process level. So we don't want to protect users from each other, but we would like to protect processes from each other. And also an important thing that we wanted to have, we didn't want to change the enforcement model, the current Linux enforcement model too much. So the goal was to make a minimal change to it. And of course things like good level of flexibility, granularity, some concept to be easy to understand even for a typical user, let's say not only for specialists. And we did a lot of analysis of current security frameworks and just access control frameworks and some of them are listed in the slide. And based on these analysis, I don't have time to explain it here. But actually we understood that there was no any of these frameworks which fit our criteria. And that's why we decided to go with our model. And I hope in the next slides I could explain it a bit. There's not much time, but let's try. So if we start from beginning, so what are the principles and key concepts we're using? So the first one is, let's say, very obvious principle. It's called the principle of list privilege. So the principle, it says, is that every application should be able to access only limited set of resources which are needed in order to accomplish its intended task. So not any possible task, intended task. And this is important in principle of list privileges. So you don't give more privileges to application with its needs to have in order to make its function. And I think it's very good principle and basic principle of many access control frameworks and security frameworks in general. And then we have this new concept which called here, protected resource. So before on my platform, all resources were available by default. So you call the IPI to get, let's say, a location of the current location of the user. And you get location back. But now some of these resources will be projected. So examples here, like for example, cellular functionality. So the reason to protect these resources, if the misuse of such resource could cause a harm, first of all, to user or to manufacturer of a device or various different scenarios. So let's consider it to be protected resource. We don't have any finalists. The work is real in progress. So they are not finished with face, whole with platform security. But they are on building it, they are in process of building it. And then each of these protected resource will be described with resource token. So resource token is like abstract name, abstract string describing this resource. And this will be a credential also for a process. So if a process would like to access our protected resource, it need a corresponding resource token in its credentials. And then our application also, from now it has to declare the resources it needs. And for this one, we will have this AGS manifest file. And I'm going to introduce in more details in the next slide. And also important thing about our security framework, there is no any security APIs by default. So you don't have to change your application in order to use some special security APIs. You can just use the standard one and benefit from security framework which is underneath. So couple of words about AGS manifest file. So in my platform, the software distribution is done inside Debian packages. And this AGS manifest file is an optional XML file inside the Debian package. So optional means that if you don't need any particular resources, you don't have to put it there. And then this file, as I said, declares needed resources and also provided resources because our models or resource token model is dynamic. So any new package it comes, it could introduce a new resource that it personally would like to control and protect. If it has some special, for example, database, its own special database which would like to protect, it can define a new resource for doing it. So it's not limited in any way with the concept. And then this file should be generated automatically by SDK, given a source code of your program so that you don't have to figure out actually what kind of resource tokens my program needs in order to function normally. And there is a couple of other stuff about this AGS manifest file. But I would like to introduce the last concept here, which is called application identifier. So this is the unique identifier of an application on a platform. It's supposed to preserve during whole lifetime of an application on the device. And it constructs it in a following way. So it from identify software source where this application came from, a package name and the application name in case there are many or binaries, many applications inside of the package. And we will use this concept a bit later. So it's quite important one. So still a couple of words about software distribution. So as I said, software comes inside Debian packages. And from device point of view, from application manager point of view, each package has a software source. So in classical way, it's based on repository signing. So classical Debian distribution way. It's the source of software repository. Or it can be also any virtual entity if we use the also going to support package signing. So it also be single developer or web page or somebody who has a key pair can sign a package. Also so as I said, that for in order to be recognized, this software source has to has an asymmetric key pair and public key needs to be known for device. And private key used to send the packages quite standard things. And on the device, each software source is assigned a trust level. And this trust level, we will basically mostly use for, let's say, we'll call it update rule. So if you have some package that came from our trusted source, very much trusted source, you should not be able to update this package with the source of less trust. Because it may be, it may be uses an attack against the user with users is nice update which is available under, through its, for example, application manager, which nice update of some system, very important system functionality that comes from some completely unknown, maybe even malicious source. So this is the way to prevent such an updates. And I will move forward. So I just security policy. So as I said in my first slide, with security policy, usually it's a control point of whole platform security. And this is our control point. And by the way, name I just doesn't, I know that there is somebody else who is using the same name. So I think it's just collision of names happened. So we don't have anything to do with that edges. So I just security policy. It contains in mapping between software sources and allowed credentials for that source. So there's example here below, but where it's like free software sources there. One is it knock up now one in my mother torque. So open source development portal. And then there is a list of resource tokens, which the source can potentially grant for an application. So if an application comes from the source, my mother torque, it can get user date can get access to user data or seller functionality if it requires it and it's just manifest file. And this policy can be changed for different set for different devices in order to provide a different security levels on the devices. So this policy can be very strict or very light weight and this how you can change the security policy. And now let's take a look on our installation time. So how the components interacting whichever and how actually the application it then gets the runtime credentials. So the application arrives to install together in the debit package together for ages manifest install or consult the agent security policy to get the allowed set of credentials for that software source because it can determine the source of this application. And then based on this I just manifest an agent security policy entry. It computes a rule. So used to the call intersection rule, which I will show in the next slide and it computes runtime credentials of a process and writes it to the file here called credential position list. So let's take a look on this intersection rule. So very easy. So we have ages manifest inside the package which declares what kind of application would like to access. So in the example on the right side, it's user data and seller. So application would like to get access to user data and seller functionality. And then it comes from the software source and the software source declares what kind of credentials this application can get if it arrives, if it was certified by that software source. And an example here, there is user data and location. So an advantage result credentials set result runtime credentials set here for the example contains only user data. And this is because it can get the seller, it requested the seller here and I just manifest, but it can't get it because the software source, this software source can't grant this resource. It doesn't have enough trust to grant this resource. And it also doesn't get location because it simply didn't request for location. So didn't say and I just manifest what it needs location. And this result credential set is actually the result runtime credential set which will be added to the process. And here's the runtime. So what happens when the application starts? So at the moment when it starts, we have a component called process credential assigner which goes to this credential position list. It finds the entry related to this particular application. It finds the credentials, this runtime credentials which are allowed for this application. And when it loads them to the process task structure in the form of supplementary group IDs. So this is how it's done technically. And then after process start to execute and it's always have this supplementary group IDs attached to it, credentials attached to it. And then the access control happens, for example, for file system it happens as before. So there's no any changes here. So there is file access control list in the file systems and various process credentials and there's no any changes. In case of D-Bus, in the process communication, we have a small patch to D-Bus D-Mon which they only, it's like small addition to D-Bus D-Mon. The only thing with addition does it allows the D-Bus D-Mon to take into consideration the supplementary group IDs. Because by default D-Bus D-Mon takes and when it makes its access control decision, it takes into consideration only user ID and group ID from static files. And then D-Bus D-Mon loads the process credentials and D-Bus policies, so D-Bus configuration file called D-Bus terminology. And then it can make an access control decision. And they're going to be also third way for application to make an access control. It can do it by itself. So it can call our leap-grids library. So we'll provide a special library to get credentials of another process. And then it could check for a special credentials it needs. And then it make a decision if you'd like to have this application accessing some IPI or get some particular data. And just to finish with access control part, I would like to explain shortly this shared libraries case. So what happens when the application try to load a shared library? So in the example here, we have an application which has two resource tokens and it's credentials, seller and user data. And we'd like to load library A. And we have like a bit of information here with suppose library A comes from very strange source. And this source is not unknown to device security policies. So it's not known. It's unknown source. And what happens? So the application sends a request to Kernel to load the library. Kernel redirected to our library checker component, which gets the credentials of application, seller and user data. It will determine the source of the library. And it will load the credentials that corresponding to that source. And then it will simply make sure that both sets are matching. And in this case, there is a mismatch because application has access to seller functionality, but the library source can't grant it. So unknown source can't grant it. And in this case, the loading of library fails. And this is needed from security point of view in order to prevent with our trusted processes, so it's very untrusted chart libraries because after the library is loaded to the process, it's in the process context, so it gets access to the same things that process gets. So very simple rule to avoid these things. And then in case it's a library B, which comes from the source which can grant seller and this example, the loading will succeed and everything is fine. So let's move on to the integrity protection now. So we have two main components here. First one is HSValidator. So this is the component which ensures the integrity of all executables and all different executables like binaries, libraries, scripts on the platform. So just a small picture how it works. So we have an application binary, which is about to be started. We have HSValidator, which will calculate the hash of this binary. And then it will get the reference hash for this binary from special storage. And the storage is populated during the installation of the corresponding package which brought this binary in. And it will try to match these hashes. And if everything is fine, so the hash is matched, then the binary can start to execute and everything is fine. But if there is a mismatch, the integrity protection policy will be taken into use. And now it's very simple. So currently if there is a mismatch, the binary is simply not allowed to be loaded. Because if the binary was modified on the device and not via software update, so just simply modified, there's probably something wrong with this binary. And then the storage of reference hashes is also needs to be, we need to protect the storage because it's a very important part of information. And for this we use the component with the HHS protected storage. It's in the next slide. So this component can be used and is used to ensure the integrity of data and configuration files. So I also get a small example here. So we have an application which has some data and configuration files. And suppose it would like to protect the integrity. The integrity. Yes. Can applications also put data on that protected storage? Yes, so it can be used for applications as well. It just, so I will explain, it's actually simply, it's not, it doesn't have any size. It simply allow, add you a signature or encryption over it. So it's just your data. It's not any particular size. So you just use the services to, we will consider it in a picture to encrypt or send the data. So you have this HHS protected storage, it's a library which you can use. So you can call the IPI of this library to kind of place these files in the protected storage if you would like to guarantee integrity. But in principle, it will just sign the data in its own way. And then every time you would like to check if your data is still okay, you can use a different IPI from the same library which like check integrity on a high level. And it will get the signature, it will verify the signature, and it will report you the status. So it will say if this integrity of this data is okay or not. And it's up to you what to do afterwards. So you can, even if it's integrity, it's not, if the file will be modified, maybe you will decide to use it anyway. But it's just a mechanism that you can use. And also this protected storage provide you not only integrity protection, but also encryption. So it could provide you, so you can use it to store securely the files which you would like to encrypt even. And this even survives the offline attacks. So it's really encryption here. And just to finish, I think I have a couple of minutes left. Let's move to our IPC communication. So yes. Pardon? So technically it's how on the disk that's encrypted? Yeah, it's simple file. You can open it and you can see what all stuff is encrypted where you can't even. So you can open it in normal way, but you will see that the content is encrypted. It doesn't make any sense. But the key will eventually be stored somewhere, right? The keys are stored in hardware. So you don't have to worry about it. But which hardware stores the key? We have this, but I didn't mention it in the first slide, but we call trusted execution environment. So this is the hardware and the embers which we are using. Why do you see the embers? For not mobile world, for PC world, there is a TPM. For mobile world, there is a different technology. But you don't have to worry about it. So you don't have to worry about key management in this case at all. That was the question, how you protect the file, how you protect the storage? But if you have a signature, so usually how the signature works, so there is a hash computed and we verify the signature of the file. But you don't have to really kind of call the special IPS to verify the signature. You have only one IPS, okay, check integrity. And this does all this cryptographic things in behind. And it comes out of the key security, the key is like storage, hardware, and the other part of it. Yeah, pretty much. So I think this is the last slide, so let's go over it. So here's another situation. You have an inter-process communication inside a device and you may be afraid that while you're transferring something, for example, over D-buzz, you get somebody kind of read the data. So here have two applications, which application one would like to send it to application two, or this kind of cloud thing, we call here potential entrusted zone, for example, it could be D-buzz or any other inter-process communication. And then what application one can do, they provide also library, we call it MIMO-CREAPT library, which it can ask this corresponding IPF from the library to sign this data in this case, and it will be, the data will be just returned together with signature. And then the data, when the signature can be transferred over, for example, a D-buzz or anything else, and then an application two can use the same library to check if this data really comes from application one. And again here, the good thing, you don't have to worry about any key management to establish a key, so to do everything is done again in hardware, all the key management is done, and there is very convenient IPAs to use to actually check these things. So the same could apply for encryption, so that you can encrypt some data using MIMO-CREAPT IPA, you can transfer the data over, again, example, D-buzz, and then another application could decrypt this data only if it possess some, or for example, resource token, mechanism of resource token is used here as well. So you can encrypt the data and say everybody who has user data, access to user data can decrypt this data, or everybody who has access to location data can decrypt this data, because I know that inside there is location data, so it's very convenient and it's very flexible. This is how you can also, with the usage of another library, you can secure your IPC communications. And short conclusions, so our goal is to open source most of our security framework, it's not only up to us, it's coming from a company, but we'll try our best. And then they actually already created a public project, it's called MIMO-6 platform security, and you can find it in MIMO-tourist.org. So we already have one repository under there, it hosts Libcrets library, so you can go check it out and start watching it. We really hope that we will add more repositories very soon. And at the end of the presentation and later I can answer any questions you have. And the main thing while we're here, because we would really like to get feedback from you and your opinions about our security framework, because it's the only way to get it better, so we won't get it better if we close it and say that nobody knows about it, and we try to make it very secure. So we don't believe in it, we don't believe in security, but in security. So we are here, we are talking about it, and we would like to get feedback for it. Thank you for your attention. So if there are questions. Yes. Very basic thing, it affects MIMO as we have it now. What happened to the principle of least surprise? I get this device, I want to install something. It's like, I get to install SSH and no can do, I need SU for it. So how do I set a password? I can find no information on that. And this is a principle of maximum surprise to a geek that you can't set up, you haven't got your own password. You mean the password for what? For? Well, so that I can run sudo. I have a box, I just need to set a password. I don't know actually about current devices. Sorry? I don't know about current, you mean that when you got this device, you would not be able to run it as a route or? Yes, I mean I have to install a package called extras and get a root shell on it, which means I've got a password as route, no security. No, but I think they're going to work on it so that it will be protected. To a geek that says I've got no security on here. I don't know much about the previous devices. I don't really work even for these kind of devices. I guess you're speaking about MIMO5 release. So I don't even, I can't even say anything about that one. I don't even work for that one. Sorry. Any other questions? Two questions. You had the access control service was based on the software source, on the repository. Is it also more fine-grained? I mean if there's a repository with solutions program that I want to accept data that I have another tool that I want to access my data, it's kind of useless to only be able to set the global for that one more repository and not program. Is there more time for that? But access control is not per repository, so it's really per program on the device. So the repository, the mechanism is a way that, so the, the, the, the, the, the, the the, the, the, the, the application of the device has its runtime credentials. So for example, access to the, some private access to user data access to location. But there is a control mechanism. How he gets, so for example, if it comes from very untrusted source, some source which there's no reputation whatsoever and don't trust this source, then it won't be able to get actually are, it can ask for many things and just manifest file, but it won't be able to get them during runtime. Did I misunderstood that source, this means repository or does it mean something else? It can mean a repository in a classical way. It can mean also, what I said, we're going to support package signing. So it can also mean that it's really prepared whenever who has a key pair. So. And the other thing you're example I had is that the FPC was talking about the resources that the application can address. I guess you also control which resources it can offer before you said which program can also offer. No, actually, so the application can, the package can provide a new resource. It will be, it can't provide some generic resource. So it can overwrite the current resource, but it can provide a known resource. It will be the kind of the space name will be kind of local to package so that we don't, it doesn't conflict with memory resources, but it can provide any resource. There's no actually restrictions in that one. Yes. When a file is in the protected store mode, does that happen in a performance impact? Because we have databases quite large with a lot of metadata. The speaker bytes in size are not very, have to be very fast. And yet our database probably going to have to be encrypted somewhere along for at least a large portion of the data. So I wonder about performance impact. There's a single line database. So this protected storage, which is going to be encrypted varies. So it's probably should not be used for the database cases because the database, so they are using hardware for their hardware accelerators to speed up the process. So it's, it's actually quite fast, but for database cases when you need to access like very often the database, it's probably not the best solution. So they're actually working on one more solution to, they're working on better solution for special for that cases. I hope they can update on this one soon. Yes. When does the user come into the picture? Is the user ever asked, do you really want to do that? You're asking about user prompting. So I don't know. I can't really comment on this one in case we will have it or not yet. So we have to wait a bit. So we, it's really working with progress now and the current thing that I'm presenting hits things that we already decided to do. I have a different question. What about side channel attacks? I mean you have very trusted processes running in parallel with very untrusted ones on the same device, on the same chip. I mean if I can measure various things, I might be able to get secret visa just by measuring. This can happen even over the next. Yes. So I'm not a hardware person. So I understand what you're talking about with side channel attacks, but I think we have hardware persons who knows about it. You're not talking even about offline attacks, but I get the device and I'm trying to take the keys out of the TPM. I'm talking really about the two processes running on the same machine and mori-con each other. And just by that they might be able to find things about themselves. I understand the only problem with that really, I'm not a hardware person. I don't know Janne if you can comment where to add one. I cannot say that such an attack is generally ignored. There are no tools to them to get involved. Well then Janne, I didn't sayga question. I think the best of this trust is. Okay, have a question. Would I be able to still make the package after privileges? I mean, I'm really convinced that the package is not equal because it's my own package. Would I be able to convince the package manager and become an everything? What do you mean to install your own package? Yes, we'll each have a privilege of one. Okay, we should be very careful about each and every privilege. So, I think that the privilege is that you have to actually, in order to get it, you have to be very, very trusted. And I'm not the one, I'm just a technical person. So, I don't know to whom these privileges will be given, like for example, DRM privilege. So, this is very sensitive privilege you'd have to protect. But in any case, for example, I have my motor torque side. So, my very short repository is there. We're going to have quite high trust level probably. Again, I don't know. I'm not the one who defining these policies. So, I'm presenting the framework who actually can do many things. I'm not the one who will decide. But I think in my motor torque, you should be able to do this. Yeah. So, will I be able to say modify the list of the trust sign in the source? Because I mean, it's my advice after all, right? So, am I going to change the decision to be, the decision to talk to my... Yeah, I understand. So, if you go to this, whenever presenting these two modes at the beginning, so if you go to this first mode, you're allowed to do everything. You're allowed to modify the security policy. You're allowed to create your own... You're allowed to trust, I don't know, maybe your friend repository the most, and then you say that, no, I don't trust with... And something like this. But in that mode. Yes. Okay, can I explain that? If he goes to that mode, will my encrypted files be gone from his device? So, if you go between the modes, so the encryption is... So, this is one thing we have to... It's nice to be encrypted for sure. So, a source that doesn't want somebody who is not trusted to look at the data. So, if you had some data encrypted using this, for example, project storage in this first mode, which is both like, shipped with DRM things, when you move to open mode, this won't be able to do encrypted data because they don't have any control of the kernel and they can't actually preserve, to guarantee anything. So, this is just a, like, the thing. But you can still, in that mode, use the encryption and then it will be different encryption. The keys are available. Yes. So, this key is really valuable. How do I back them up? No. So, the key is bound to the device. So, you can't back them up because you can't actually transfer them between devices. The device is dead. They are a little more like that. There is a project in MIMO, which is called Backup Service, which will be able to back up your data in very complicated projects, or complicated process, how it will be done. So, you will be able to back up your data, but not the keys. The data is not useful to me, but I have to keep track of it. No, but the keys... No, the keys are... No, the data would be probably... I don't know how it will work again. I'm not from there, but it probably will be encrypted and encrypted in some different keys and then pushed back up, for example. But then, to give note, yeah, my data, right? No. Or, I'll say a third part. Yeah. But I have to give away my data. It's not gonna be... But it's your choice to use it or not to use it. You don't have to use it when with encryption service. I feel like I'm five years ago, because this platform, as I understand it, and as a professional show, is functionally pretty much equivalent to DPM in those aspects, so this DPM has been dramatically standardized and dejected by it. So, my question is, to turn this into some form of constructive question, rather than a random question, I'm not sure what I would like it to do. Do you expect it to be competitive with version three of the DPLs, which could prevent exactly this kind of platform, and there's no competition to any of the discussion that has happened in the community regarding DPLs, which are formulated in the DPLs. So, do you expect it to be competitive or do you expect it to be in the current DPLs? So, my am currently is DPL two, and I don't have any... I'm not the one who is even deciding these things, but my am currently is DPL two. And that's why the kernel of DPL two I will say that one. So, I think... Yes. I just want to say one last slide. I think it's the good loader... Okay....checking if... So, my am on check is the......fifth of this one. Hmm? My am on check is the good loader is from Naki. I understand that. Yeah. I don't know. For me, I'm not familiar with my amour, but for me, my amour is like a small PC, and I will be quite upset if a thing, but would check if the loader is from thing, but... And... Yes, we have this one. So, what are your concern about? I would like to change the loader. For... And... Because many have a OS operating system that this loader is unloading, I wouldn't be......not about the loader, but the loader is a certain system... So, I would like to put a different operating system on this device. No, I would at least load it, because maybe some OS has some needs, for example. But in this... This loader maybe doesn't load my OS, and I want to change this loader. And in the NPC, you can change a loader, but not in the amour. It's a bit confusing. You can have a loader there on that, on such a free lift, if you like. I can launch another loader. No? Yeah, I understand. I want to launch a loader for long time OS. But there should be an enforcement point for us. I mean, there should be a point where we'll... Actually, we'll make decisions here, and we have to keep at least something... Yeah, I mean, why... In all PCs, the... The... The... The loader doesn't import the loader, but not the... The loader needs to import the loader. But if you can get still your own loader, like on top, why do you want to get rid of this loader? Why not? That's probably not a good reason enough yet. You can call me, but you can consider it like you buy a... Yeah. Yeah. Still, why do you want to send a loader in your thing, but as well as in your company? Okay. In your case, get ready. I'm afraid I have to finish for now, but I will be available, and together with my colleague, will be available today, the whole day for questions. But I think I have to finish now. Thank you.
 I think it's already a bit after two.  So good afternoon to everybody and I hope everybody had a nice lunch.  And this I think the first session for security, the first talk of the security session.  And my name is Elena Rechitova and I'm coming from Nokia My Amour platform.  And I don't know if many of you are familiar with this N900 device.  So this is a device which runs open source development platform.  The name is My Amour.  I guess there is even a competition where you can get some of these devices today.  And I'm working for platform security in My Amour and the new platform security which  is coming for My Amour 6 release.  And this presentation is supposed to give a short review about My Amour platform security.  And let's see how much time we have.  I would like also to leave the time for questions.  So here is a short outline.  So first of all, I will just briefly talk about what is platform security or to be sure that  we speak the same language when we say this term platform security.  Then we will take a look on our different two different device modes of operation for  My Amour 6 device.  And I will say the reasons for these two different modes.  And also during the boot, we will take a look on a boot process to understand how you can  get these two different modes loaded.  We will take a look on access control, one of the primary things in security framework.  And we will take a look on different things related to access control.  Also integrity protection.  And we will finish with security of inter-process communication.  So what is platform security?  So here is in the slide it says that it's set of mechanisms and techniques which are  used to protect the entire software platform.  So let's imagine we will try to build a house which called platform security.  So what are the bricks here?  So what are the mechanisms and techniques here?  So in the bottom of our house, there is a big brick called hardware enablers.  So this is actually a very important piece for whole platform security.  So these hardware enablers are needed in order to guarantee that software, the security software  which runs on top of it, it's actually really secured from the software and possible attacks.  When there is free middle bricks which here stand for integrity protection, access control  and privacy protection.  So integrity is to, we need to protect integrity in this case.  It's integrity of our binaries, executables, also configuration data files.  So everything which we would like to be sure that it was not modified during the lifetime  of a device.  Of course, authorized modification are allowed but non-authorized or not.  And when the access control very, a known thing in security frameworks.  So who is allowed to access what and why and so on.  And the last one is privacy protection.  So here it mostly means the encryption of user data or your private data for reasons  that you would like to keep them secret and not accessible for anything else.  Then a set of for example limited programs.  And on the side of all this bricks of our house, there is a key management.  So key management is needed on all of these levels.  So that's why it stands aside.  And on the top of house there is a roof called here security policies.  So this is the control point of all platform security.  So security policy defines how all these mechanisms are working and what is the needed security  level.  So this is really just a couple of words to explain what is platform security.  And so now let's move to the interesting part.  Here is a slide called device modes.  So many people are afraid.  So my more platform is an open source development platform.  And many people are afraid that now when I'm starting to speak about platform security,  it means okay, the platform will be closed.  So when security, there is like a common understanding when security comes, the platform goes closed.  So that's why I have this first slide already explaining you that it's not going to be the  first.  And we will take a look on the first mode of device operation.  There is no particular name for this mode.  I don't know.  People will probably come up with interesting names after.  But these mode of device operation is the same mode as we used to have on previous memory  releases.  So for example, this device runs MAM5 release.  So you can do whenever you want with a device, you can compile, build your own kernel.  You can run your own kernel.  You can make any level platform development.  So whenever you were able to do before, you can still do.  And there is a special mode even for you to do it.  So the only thing that you need, you would need to put your device, MIMO6 device to this  mode and then you can do things that you would like to do.  There is a second mode, which is going to be for MIMO6.  And the reason for introducing this mode is that we would like to have to even extend  even more our developer offering.  So we know that there are developers who would like to make a bit of profit from their own  very good software.  And we would like to give a choice to them to do it.  So it doesn't mean that when it says here copy protection, it doesn't mean that all  software needs to be copy protection and it will be DRM protected.  It's just a choice for you.  So if you would like to have the possibility to own money on this platform, you can use  the copy protection.  You can put your software in the DRM.  But if you don't want to do it, there's nobody who will force you to do it.  So you can still distribute open software and it's more than welcomed.  And there will be also a way to move between these two modes.  And this can be done with a booting process and next slide will show how actually you  can reach each of these modes.  So the boot process is very high level.  So not many details will start from a boot ROM which will first check integrity of the  loader.  And if integrity of the loader is okay, the loader can continue.  So the loader starts to run and it will check the integrity of software image.  And if it's software image is considered to be Nokia sign software image, then this second  mode which I showed on the previous slide.  So the mode which provides you DRM protection and access to application store which you  know it called OV store.  So you can load this mode because the kernel is fine, the software image is fine and it's  Nokia sign software image.  So let's now take a look on what happens when some of these components are not fine.  So if the loader is, if integrity of the loader failed, then we can't allow this because we  can't allow entrusted loader.  So the device goes to reset so they're not allowing the change of the loader.  But if integrity of software image failed, so there is still one question to be asked  here.  So if this device is SIM locked, so SIM locked here means that you for example buy the device  from operator, usually it's less price, but you have to use it with the same, I don't  know, I never tried to do it.  So you probably have to use it for one year with some SIM card and it's locked to the  SIM card.  So if the device is SIM locked, then in picture it says that the other image is not allowed,  but it's not up to us.  So it depends on operator, on your contract with operator, maybe some local legislation  in the country.  So we really don't have any stand on it.  So it's up to operator, but it's also up to you not to buy these devices from the operator.  And just to mention this part, and then if device is not SIM locked, then we will allow  to boot any unsigned kernel, any unsigned software image.  There is only one step which will happen in between here with books saying restrict security  functionality.  So here, this step we need in order to protect things like for example DRM keys, because these  keys can't be compromised and we need to disable these keys.  And there are also a couple of small things which happened here, but after these things  are done, you can load pretty much any, so you can load any unsigned software image.  So the one you did and the one you compiled, so nothing prevents you to do it.  So this is again high level with boot process.  So let's move to access control part now.  And here we got actually quite many questions already that there are many existing access  control solutions in whole operating systems.  And the question obviously of which we were asked is why are we doing our own access control  here?  And here's a slide which presents a bit of our reasoning why we decided to go this way.  And first let's start what we had before.  So what does our, what do the previous memory devices have?  So the only thing we actually had it was the classical Unix access control model, which  is a very user-centric model.  So it was the threat, the threat model at the time when it was developed was there was  number of users who were using the same PC and the goal was to separate data of these  users with one, let's say, some bad user can't read your email, so can't read your private  files.  So this was a threat model when this classical Unix access control was created.  And it was discretionary access control, so user and owner of the file could change the  ownership of the file.  And later the situation, we were trying to change this, let's say, extend the classical  Unix access control by reducing, for example, Pozik's capabilities.  And it was, I think, a very good idea, but they're not really in use now.  So for example, root by default has all of them and others, users none.  So kind of the concept is there, but it's not really used.  And then our criteria, so my demo devices are mostly one user devices.  So there's no actually need to protect one user from another user.  So what, in the threat model now is that we would like to protect data between the processes  because there's many applications that user installs.  And the typical user, it doesn't really understand, and the program may look very nice and things  that can be malicious.  So users don't understand it.  They may install malicious programs and they may try to steal the data and do other harmful  things.  So we would like to have access control, which is in process level.  So we don't want to protect users from each other, but we would like to protect processes  from each other.  And also an important thing that we wanted to have, we didn't want to change the enforcement  model, the current Linux enforcement model too much.  So the goal was to make a minimal change to it.  And of course things like good level of flexibility, granularity, some concept to be easy to understand  even for a typical user, let's say not only for specialists.  And we did a lot of analysis of current security frameworks and just access control frameworks  and some of them are listed in the slide.  And based on these analysis, I don't have time to explain it here.  But actually we understood that there was no any of these frameworks which fit our criteria.  And that's why we decided to go with our model.  And I hope in the next slides I could explain it a bit.  There's not much time, but let's try.  So if we start from beginning, so what are the principles and key concepts we're using?  So the first one is, let's say, very obvious principle.  It's called the principle of list privilege.  So the principle, it says, is that every application should be able to access only limited set  of resources which are needed in order to accomplish its intended task.  So not any possible task, intended task.  And this is important in principle of list privileges.  So you don't give more privileges to application with its needs to have in order to make its  function.  And I think it's very good principle and basic principle of many access control frameworks  and security frameworks in general.  And then we have this new concept which called here, protected resource.  So before on my platform, all resources were available by default.  So you call the IPI to get, let's say, a location of the current location of the user.  And you get location back.  But now some of these resources will be projected.  So examples here, like for example, cellular functionality.  So the reason to protect these resources, if the misuse of such resource could cause  a harm, first of all, to user or to manufacturer of a device or various different scenarios.  So let's consider it to be protected resource.  We don't have any finalists.  The work is real in progress.  So they are not finished with face, whole with platform security.  But they are on building it, they are in process of building it.  And then each of these protected resource will be described with resource token.  So resource token is like abstract name, abstract string describing this resource.  And this will be a credential also for a process.  So if a process would like to access our protected resource, it need a corresponding resource  token in its credentials.  And then our application also, from now it has to declare the resources it needs.  And for this one, we will have this AGS manifest file.  And I'm going to introduce in more details in the next slide.  And also important thing about our security framework, there is no any security APIs by  default.  So you don't have to change your application in order to use some special security APIs.  You can just use the standard one and benefit from security framework which is underneath.  So couple of words about AGS manifest file.  So in my platform, the software distribution is done inside Debian packages.  And this AGS manifest file is an optional XML file inside the Debian package.  So optional means that if you don't need any particular resources, you don't have to put  it there.  And then this file, as I said, declares needed resources and also provided resources because  our models or resource token model is dynamic.  So any new package it comes, it could introduce a new resource that it personally would like  to control and protect.  If it has some special, for example, database, its own special database which would like  to protect, it can define a new resource for doing it.  So it's not limited in any way with the concept.  And then this file should be generated automatically by SDK, given a source code of your program  so that you don't have to figure out actually what kind of resource tokens my program needs  in order to function normally.  And there is a couple of other stuff about this AGS manifest file.  But I would like to introduce the last concept here, which is called application identifier.  So this is the unique identifier of an application on a platform.  It's supposed to preserve during whole lifetime of an application on the device.  And it constructs it in a following way.  So it from identify software source where this application came from, a package name  and the application name in case there are many or binaries, many applications inside  of the package.  And we will use this concept a bit later.  So it's quite important one.  So still a couple of words about software distribution.  So as I said, software comes inside Debian packages.  And from device point of view, from application manager point of view, each package has a  software source.  So in classical way, it's based on repository signing.  So classical Debian distribution way.  It's the source of software repository.  Or it can be also any virtual entity if we use the also going to support package signing.  So it also be single developer or web page or somebody who has a key pair can sign a  package.  Also so as I said, that for in order to be recognized, this software source has to has  an asymmetric key pair and public key needs to be known for device.  And private key used to send the packages quite standard things.  And on the device, each software source is assigned a trust level.  And this trust level, we will basically mostly use for, let's say, we'll call it update rule.  So if you have some package that came from our trusted source, very much trusted source,  you should not be able to update this package with the source of less trust.  Because it may be, it may be uses an attack against the user with users is nice update  which is available under, through its, for example, application manager, which nice update  of some system, very important system functionality that comes from some completely unknown, maybe  even malicious source.  So this is the way to prevent such an updates.  And I will move forward.  So I just security policy.  So as I said in my first slide, with security policy, usually it's a control point of whole  platform security.  And this is our control point.  And by the way, name I just doesn't, I know that there is somebody else who is using the  same name.  So I think it's just collision of names happened.  So we don't have anything to do with that edges.  So I just security policy.  It contains in mapping between software sources and allowed credentials for that source.  So there's example here below, but where it's like free software sources there.  One is it knock up now one in my mother torque.  So open source development portal.  And then there is a list of resource tokens, which the source can potentially grant for  an application.  So if an application comes from the source, my mother torque, it can get user date can  get access to user data or seller functionality if it requires it and it's just manifest  file.  And this policy can be changed for different set for different devices in order to provide  a different security levels on the devices.  So this policy can be very strict or very light weight and this how you can change the  security policy.  And now let's take a look on our installation time.  So how the components interacting whichever and how actually the application it then gets  the runtime credentials.  So the application arrives to install together in the debit package together for ages manifest  install or consult the agent security policy to get the allowed set of credentials for  that software source because it can determine the source of this application.  And then based on this I just manifest an agent security policy entry.  It computes a rule.  So used to the call intersection rule, which I will show in the next slide and it computes  runtime credentials of a process and writes it to the file here called credential position  list.  So let's take a look on this intersection rule.  So very easy.  So we have ages manifest inside the package which declares what kind of application would  like to access.  So in the example on the right side, it's user data and seller.  So application would like to get access to user data and seller functionality.  And then it comes from the software source and the software source declares what kind  of credentials this application can get if it arrives, if it was certified by that software  source.  And an example here, there is user data and location.  So an advantage result credentials set result runtime credentials set here for the example  contains only user data.  And this is because it can get the seller, it requested the seller here and I just manifest,  but it can't get it because the software source, this software source can't grant this resource.  It doesn't have enough trust to grant this resource.  And it also doesn't get location because it simply didn't request for location.  So didn't say and I just manifest what it needs location.  And this result credential set is actually the result runtime credential set which will  be added to the process.  And here's the runtime.  So what happens when the application starts?  So at the moment when it starts, we have a component called process credential assigner  which goes to this credential position list.  It finds the entry related to this particular application.  It finds the credentials, this runtime credentials which are allowed for this application.  And when it loads them to the process task structure in the form of supplementary group  IDs.  So this is how it's done technically.  And then after process start to execute and it's always have this supplementary group  IDs attached to it, credentials attached to it.  And then the access control happens, for example, for file system it happens as before.  So there's no any changes here.  So there is file access control list in the file systems and various process credentials  and there's no any changes.  In case of D-Bus, in the process communication, we have a small patch to D-Bus D-Mon which  they only, it's like small addition to D-Bus D-Mon.  The only thing with addition does it allows the D-Bus D-Mon to take into consideration  the supplementary group IDs.  Because by default D-Bus D-Mon takes and when it makes its access control decision, it  takes into consideration only user ID and group ID from static files.  And then D-Bus D-Mon loads the process credentials and D-Bus policies, so D-Bus configuration  file called D-Bus terminology.  And then it can make an access control decision.  And they're going to be also third way for application to make an access control.  It can do it by itself.  So it can call our leap-grids library.  So we'll provide a special library to get credentials of another process.  And then it could check for a special credentials it needs.  And then it make a decision if you'd like to have this application accessing some IPI  or get some particular data.  And just to finish with access control part, I would like to explain shortly this shared  libraries case.  So what happens when the application try to load a shared library?  So in the example here, we have an application which has two resource tokens and it's credentials,  seller and user data.  And we'd like to load library A. And we have like a bit of information here with suppose  library A comes from very strange source.  And this source is not unknown to device security policies.  So it's not known.  It's unknown source.  And what happens?  So the application sends a request to Kernel to load the library.  Kernel redirected to our library checker component, which gets the credentials of application,  seller and user data.  It will determine the source of the library.  And it will load the credentials that corresponding to that source.  And then it will simply make sure that both sets are matching.  And in this case, there is a mismatch because application has access to seller functionality,  but the library source can't grant it.  So unknown source can't grant it.  And in this case, the loading of library fails.  And this is needed from security point of view in order to prevent with our trusted processes,  so it's very untrusted chart libraries because after the library is loaded to the process,  it's in the process context, so it gets access to the same things that process gets.  So very simple rule to avoid these things.  And then in case it's a library B, which comes from the source which can grant seller  and this example, the loading will succeed and everything is fine.  So let's move on to the integrity protection now.  So we have two main components here.  First one is HSValidator.  So this is the component which ensures the integrity of all executables and all different  executables like binaries, libraries, scripts on the platform.  So just a small picture how it works.  So we have an application binary, which is about to be started.  We have HSValidator, which will calculate the hash of this binary.  And then it will get the reference hash for this binary from special storage.  And the storage is populated during the installation of the corresponding package which brought  this binary in.  And it will try to match these hashes.  And if everything is fine, so the hash is matched, then the binary can start to execute  and everything is fine.  But if there is a mismatch, the integrity protection policy will be taken into use.  And now it's very simple.  So currently if there is a mismatch, the binary is simply not allowed to be loaded.  Because if the binary was modified on the device and not via software update, so just  simply modified, there's probably something wrong with this binary.  And then the storage of reference hashes is also needs to be, we need to protect the  storage because it's a very important part of information.  And for this we use the component with the HHS protected storage.  It's in the next slide.  So this component can be used and is used to ensure the integrity of data and configuration  files.  So I also get a small example here.  So we have an application which has some data and configuration files.  And suppose it would like to protect the integrity.  The integrity.  Yes.  Can applications also put data on that protected storage?  Yes, so it can be used for applications as well.  It just, so I will explain, it's actually simply, it's not, it doesn't have any size.  It simply allow, add you a signature or encryption over it.  So it's just your data.  It's not any particular size.  So you just use the services to, we will consider it in a picture to encrypt or send the data.  So you have this HHS protected storage, it's a library which you can use.  So you can call the IPI of this library to kind of place these files in the protected  storage if you would like to guarantee integrity.  But in principle, it will just sign the data in its own way.  And then every time you would like to check if your data is still okay, you can use a  different IPI from the same library which like check integrity on a high level.  And it will get the signature, it will verify the signature, and it will report you the  status.  So it will say if this integrity of this data is okay or not.  And it's up to you what to do afterwards.  So you can, even if it's integrity, it's not, if the file will be modified, maybe you will  decide to use it anyway.  But it's just a mechanism that you can use.  And also this protected storage provide you not only integrity protection, but also encryption.  So it could provide you, so you can use it to store securely the files which you would  like to encrypt even.  And this even survives the offline attacks.  So it's really encryption here.  And just to finish, I think I have a couple of minutes left.  Let's move to our IPC communication.  So yes.  Pardon?  So technically it's how on the disk that's encrypted?  Yeah, it's simple file.  You can open it and you can see what all stuff is encrypted where you can't even.  So you can open it in normal way, but you will see that the content is encrypted.  It doesn't make any sense.  But the key will eventually be stored somewhere, right?  The keys are stored in hardware.  So you don't have to worry about it.  But which hardware stores the key?  We have this, but I didn't mention it in the first slide, but we call trusted execution  environment.  So this is the hardware and the embers which we are using.  Why do you see the embers?  For not mobile world, for PC world, there is a TPM.  For mobile world, there is a different technology.  But you don't have to worry about it.  So you don't have to worry about key management in this case at all.  That was the question, how you protect the file, how you protect the storage?  But if you have a signature, so usually how the signature works, so there is a hash computed  and we verify the signature of the file.  But you don't have to really kind of call the special IPS to verify the signature.  You have only one IPS, okay, check integrity.  And this does all this cryptographic things in behind.  And it comes out of the key security, the key is like storage, hardware, and the other  part of it.  Yeah, pretty much.  So I think this is the last slide, so let's go over it.  So here's another situation.  You have an inter-process communication inside a device and you may be afraid that while  you're transferring something, for example, over D-buzz, you get somebody kind of read  the data.  So here have two applications, which application one would like to send it to application two,  or this kind of cloud thing, we call here potential entrusted zone, for example, it could  be D-buzz or any other inter-process communication.  And then what application one can do, they provide also library, we call it MIMO-CREAPT  library, which it can ask this corresponding IPF from the library to sign this data in  this case, and it will be, the data will be just returned together with signature.  And then the data, when the signature can be transferred over, for example, a D-buzz  or anything else, and then an application two can use the same library to check if this  data really comes from application one.  And again here, the good thing, you don't have to worry about any key management to  establish a key, so to do everything is done again in hardware, all the key management  is done, and there is very convenient IPAs to use to actually check these things.  So the same could apply for encryption, so that you can encrypt some data using MIMO-CREAPT  IPA, you can transfer the data over, again, example, D-buzz, and then another application  could decrypt this data only if it possess some, or for example, resource token, mechanism  of resource token is used here as well.  So you can encrypt the data and say everybody who has user data, access to user data can  decrypt this data, or everybody who has access to location data can decrypt this data, because  I know that inside there is location data, so it's very convenient and it's very flexible.  This is how you can also, with the usage of another library, you can secure your IPC  communications.  And short conclusions, so our goal is to open source most of our security framework, it's  not only up to us, it's coming from a company, but we'll try our best.  And then they actually already created a public project, it's called MIMO-6 platform security,  and you can find it in MIMO-tourist.org.  So we already have one repository under there, it hosts Libcrets library, so you can go check  it out and start watching it.  We really hope that we will add more repositories very soon.  And at the end of the presentation and later I can answer any questions you have.  And the main thing while we're here, because we would really like to get feedback from  you and your opinions about our security framework, because it's the only way to get it better,  so we won't get it better if we close it and say that nobody knows about it, and we try  to make it very secure.  So we don't believe in it, we don't believe in security, but in security.  So we are here, we are talking about it, and we would like to get feedback for it.  Thank you for your attention.  So if there are questions.  Yes.  Very basic thing, it affects MIMO as we have it now.  What happened to the principle of least surprise?  I get this device, I want to install something.  It's like, I get to install SSH and no can do, I need SU for it.  So how do I set a password?  I can find no information on that.  And this is a principle of maximum surprise to a geek that you can't set up, you haven't  got your own password.  You mean the password for what?  For?  Well, so that I can run sudo.  I have a box, I just need to set a password.  I don't know actually about current devices.  Sorry?  I don't know about current, you mean that when you got this device, you would not be able  to run it as a route or?  Yes, I mean I have to install a package called extras and get a root shell on it, which means  I've got a password as route, no security.  No, but I think they're going to work on it so that it will be protected.  To a geek that says I've got no security on here.  I don't know much about the previous devices.  I don't really work even for these kind of devices.  I guess you're speaking about MIMO5 release.  So I don't even, I can't even say anything about that one.  I don't even work for that one.  Sorry.  Any other questions?  Two questions.  You had the access control service was based on the software source, on the repository.  Is it also more fine-grained?  I mean if there's a repository with solutions program that I want to accept data that I  have another tool that I want to access my data, it's kind of useless to only be able  to set the global for that one more repository and not program.  Is there more time for that?  But access control is not per repository, so it's really per program on the device.  So the repository, the mechanism is a way that, so the, the, the, the, the, the, the  the, the, the, the, the application of the device has its runtime credentials.  So for example, access to the, some private access to user data access to location.  But there is a control mechanism.  How he gets, so for example, if it comes from very untrusted source, some source which  there's no reputation whatsoever and don't trust this source, then it won't be able to  get actually are, it can ask for many things and just manifest file, but it won't be  able to get them during runtime.  Did I misunderstood that source, this means repository or does it mean something else?  It can mean a repository in a classical way.  It can mean also, what I said, we're going to support package signing.  So it can also mean that it's really prepared whenever who has a key pair.  So.  And the other thing you're example I had is that the FPC was talking about the resources  that the application can address.  I guess you also control which resources it can offer before you said which program can also offer.  No, actually, so the application can, the package can provide a new resource.  It will be, it can't provide some generic resource.  So it can overwrite the current resource, but it can provide a known resource.  It will be the kind of the space name will be kind of local to package so that we don't,  it doesn't conflict with memory resources, but it can provide any resource.  There's no actually restrictions in that one.  Yes.  When a file is in the protected store mode, does that happen in a performance impact?  Because we have databases quite large with a lot of metadata.  The speaker bytes in size are not very, have to be very fast.  And yet our database probably going to have to be encrypted somewhere along for at least  a large portion of the data.  So I wonder about performance impact.  There's a single line database.  So this protected storage, which is going to be encrypted varies.  So it's probably should not be used for the database cases because the database, so they  are using hardware for their hardware accelerators to speed up the process.  So it's, it's actually quite fast, but for database cases when you need to access like  very often the database, it's probably not the best solution.  So they're actually working on one more solution to, they're working on better solution for  special for that cases.  I hope they can update on this one soon.  Yes.  When does the user come into the picture?  Is the user ever asked, do you really want to do that?  You're asking about user prompting.  So I don't know.  I can't really comment on this one in case we will have it or not yet.  So we have to wait a bit.  So we, it's really working with progress now and the current thing that I'm presenting  hits things that we already decided to do.  I have a different question.  What about side channel attacks?  I mean you have very trusted processes running in parallel with very untrusted ones on the  same device, on the same chip.  I mean if I can measure various things, I might be able to get secret visa just by measuring.  This can happen even over the next.  Yes.  So I'm not a hardware person.  So I understand what you're talking about with side channel attacks, but I think we  have hardware persons who knows about it.  You're not talking even about offline attacks, but I get the device and I'm trying to take  the keys out of the TPM.  I'm talking really about the two processes running on the same machine and mori-con each  other.  And just by that they might be able to find things about themselves.  I understand the only problem with that really, I'm not a hardware person.  I don't know Janne if you can comment where to add one.  I cannot say that such an attack is generally ignored.  There are no tools to them to get involved.  Well then Janne, I didn't sayga question.  I think the best of this trust is.  Okay, have a question.  Would I be able to still make the package  after privileges?  I mean, I'm really convinced that the package is not equal  because it's my own package.  Would I be able to convince the package manager  and become an everything?  What do you mean to install your own package?  Yes, we'll each have a privilege of one.  Okay, we should be very careful about each and every privilege.  So, I think that the privilege is that you have to actually,  in order to get it, you have to be very, very trusted.  And I'm not the one, I'm just a technical person.  So, I don't know to whom these privileges will be given,  like for example, DRM privilege.  So, this is very sensitive privilege you'd have to protect.  But in any case, for example, I have my motor torque side.  So, my very short repository is there.  We're going to have quite high trust level probably.  Again, I don't know.  I'm not the one who defining these policies.  So, I'm presenting the framework  who actually can do many things.  I'm not the one who will decide.  But I think in my motor torque, you should be able to do this.  Yeah.  So, will I be able to say modify the list of the trust sign in the source?  Because I mean, it's my advice after all, right?  So, am I going to change the decision to be,  the decision to talk to my...  Yeah, I understand.  So, if you go to this,  whenever presenting these two modes at the beginning,  so if you go to this first mode,  you're allowed to do everything.  You're allowed to modify the security policy.  You're allowed to create your own...  You're allowed to trust, I don't know,  maybe your friend repository the most,  and then you say that,  no, I don't trust with...  And something like this.  But in that mode.  Yes.  Okay, can I explain that?  If he goes to that mode,  will my encrypted files be gone from his device?  So, if you go between the modes,  so the encryption is...  So, this is one thing we have to...  It's nice to be encrypted for sure.  So, a source that doesn't want somebody  who is not trusted to look at the data.  So, if you had some data encrypted  using this, for example,  project storage in this first mode,  which is both like,  shipped with DRM things,  when you move to open mode,  this won't be able to do encrypted data  because they don't have any control of the kernel  and they can't actually preserve,  to guarantee anything.  So, this is just a, like, the thing.  But you can still, in that mode,  use the encryption  and then it will be different encryption.  The keys are available.  Yes.  So, this key is really valuable.  How do I back them up?  No.  So, the key is bound to the device.  So, you can't back them up  because you can't actually transfer them between devices.  The device is dead.  They are a little more like that.  There is a project in MIMO,  which is called Backup Service,  which will be able to back up your data  in very complicated projects,  or complicated process, how it will be done.  So, you will be able to back up your data,  but not the keys.  The data is not useful to me,  but I have to keep track of it.  No, but the keys...  No, the keys are...  No, the data would be probably...  I don't know how it will work again.  I'm not from there,  but it probably will be encrypted  and encrypted in some different keys  and then pushed back up, for example.  But then, to give note,  yeah, my data, right?  No.  Or, I'll say a third part.  Yeah.  But I have to give away my data.  It's not gonna be...  But it's your choice to use it  or not to use it.  You don't have to use it  when with encryption service.  I feel like I'm five years ago,  because this platform,  as I understand it,  and as a professional show,  is functionally pretty much equivalent to DPM  in those aspects,  so this DPM has been dramatically  standardized and dejected by it.  So, my question is,  to turn this into some form of constructive question,  rather than a random question,  I'm not sure what I would like it to do.  Do you expect it to be competitive  with version three of the DPLs,  which could prevent exactly this kind of platform,  and there's no competition  to any of the discussion that has happened  in the community regarding DPLs,  which are formulated in the DPLs.  So, do you expect it to be competitive  or do you expect it to be in the current DPLs?  So, my am currently is DPL two,  and I don't have any...  I'm not the one who is even deciding these things,  but my am currently is DPL two.  And that's why the kernel of DPL two  I will say that one.  So, I think...  Yes.  I just want to say one last slide.  I think it's the good loader...  Okay. ...checking if...  So, my am on check is the... ...fifth of this one.  Hmm?  My am on check is the good loader is from Naki.  I understand that.  Yeah.  I don't know.  For me, I'm not familiar with my amour,  but for me, my amour is like a small PC,  and I will be quite upset if a thing,  but would check if the loader is from thing,  but...  And...  Yes, we have this one.  So, what are your concern about?  I would like to change the loader.  For...  And...  Because many have a OS operating system  that this loader is unloading,  I wouldn't be... ...not about the loader,  but the loader is a certain system...  So, I would like to put a different operating system  on this device.  No, I would at least load it,  because maybe some OS has some needs,  for example.  But in this...  This loader maybe doesn't load my OS,  and I want to change this loader.  And in the NPC, you can change a loader,  but not in the amour.  It's a bit confusing.  You can have a loader there on that,  on such a free lift, if you like.  I can launch another loader.  No?  Yeah, I understand.  I want to launch a loader for long time OS.  But there should be an enforcement point for us.  I mean, there should be a point where we'll...  Actually, we'll make decisions here,  and we have to keep at least something...  Yeah, I mean, why...  In all PCs, the...  The...  The...  The loader doesn't import the loader,  but not the...  The loader needs to import the loader.  But if you can get still your own loader,  like on top,  why do you want to get rid of this loader?  Why not?  That's probably not a good reason enough yet.  You can call me,  but you can consider it like you buy a...  Yeah.  Yeah.  Still,  why do you want to send a loader  in your thing,  but as well as in your company?  Okay.  In your case,  get ready.  I'm afraid I have to finish for now,  but I will be available,  and together with my colleague,  will be available today,  the whole day for questions.  But I think I have to finish now.  Thank you.
Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_0_131.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_132_179.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_180_1595.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_1596_2855.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_2856_3935.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_3936_5339.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_5340_5639.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_5640_6179.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_6180_6947.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_6948_8135.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_8136_8303.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_8304_9647.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_9648_9839.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_9840_10019.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_10020_11183.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_11184_12383.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_12384_13499.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_13500_13547.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_13548_18131.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_18132_21911.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_21912_24431.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_24432_26927.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_26928_28751.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_28752_29927.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_29928_31751.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_31752_34691.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_34692_34787.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_34788_35099.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_35100_37139.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_37140_37271.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_37272_37655.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_37656_37703.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_37704_37787.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_37788_38303.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_38304_39467.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_39468_39719.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_39720_42311.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_42312_42359.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_42360_44603.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_44604_45839.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_45840_46259.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_46260_47651.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_47652_48923.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_48924_61343.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_61344_65807.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_65808_65855.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_65856_65903.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_65904_65951.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_65952_65999.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_66000_66047.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_66048_66095.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_66096_67703.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_67704_67859.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_67860_67907.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_67908_68819.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_68820_68867.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_68868_68915.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_68916_68963.png Maemo_6_security_framework__making_happy_DRM_business_and_freedom_lovers_with_the_same_device_r08dFQ_2_68964_69090.png
I think it's already a bit after two. So good afternoon to everybody and I hope everybody had a nice lunch. And this I think the first session for security, the first talk of the security session. And my name is Elena Rechitova and I'm coming from Nokia My Amour platform. And I don't know if many of you are familiar with this N900 device. So this is a device which runs open source development platform. The name is My Amour. I guess there is even a competition where you can get some of these devices today. And I'm working for platform security in My Amour and the new platform security which is coming for My Amour 6 release. And this presentation is supposed to give a short review about My Amour platform security. And let's see how much time we have. I would like also to leave the time for questions. So here is a short outline. So first of all, I will just briefly talk about what is platform security or to be sure that we speak the same language when we say this term platform security. Then we will take a look on our different two different device modes of operation for My Amour 6 device. And I will say the reasons for these two different modes. And also during the boot, we will take a look on a boot process to understand how you can get these two different modes loaded. We will take a look on access control, one of the primary things in security framework. And we will take a look on different things related to access control. Also integrity protection. And we will finish with security of inter-process communication. So what is platform security? So here is in the slide it says that it's set of mechanisms and techniques which are used to protect the entire software platform. So let's imagine we will try to build a house which called platform security. So what are the bricks here? So what are the mechanisms and techniques here? So in the bottom of our house, there is a big brick called hardware enablers. So this is actually a very important piece for whole platform security. So these hardware enablers are needed in order to guarantee that software, the security software which runs on top of it, it's actually really secured from the software and possible attacks. When there is free middle bricks which here stand for integrity protection, access control and privacy protection. So integrity is to, we need to protect integrity in this case. It's integrity of our binaries, executables, also configuration data files. So everything which we would like to be sure that it was not modified during the lifetime of a device. Of course, authorized modification are allowed but non-authorized or not. And when the access control very, a known thing in security frameworks. So who is allowed to access what and why and so on. And the last one is privacy protection. So here it mostly means the encryption of user data or your private data for reasons that you would like to keep them secret and not accessible for anything else. Then a set of for example limited programs. And on the side of all this bricks of our house, there is a key management. So key management is needed on all of these levels. So that's why it stands aside. And on the top of house there is a roof called here security policies. So this is the control point of all platform security. So security policy defines how all these mechanisms are working and what is the needed security level. So this is really just a couple of words to explain what is platform security. And so now let's move to the interesting part. Here is a slide called device modes. So many people are afraid. So my more platform is an open source development platform. And many people are afraid that now when I'm starting to speak about platform security, it means okay, the platform will be closed. So when security, there is like a common understanding when security comes, the platform goes closed. So that's why I have this first slide already explaining you that it's not going to be the first. And we will take a look on the first mode of device operation. There is no particular name for this mode. I don't know. People will probably come up with interesting names after. But these mode of device operation is the same mode as we used to have on previous memory releases. So for example, this device runs MAM5 release. So you can do whenever you want with a device, you can compile, build your own kernel. You can run your own kernel. You can make any level platform development. So whenever you were able to do before, you can still do. And there is a special mode even for you to do it. So the only thing that you need, you would need to put your device, MIMO6 device to this mode and then you can do things that you would like to do. There is a second mode, which is going to be for MIMO6. And the reason for introducing this mode is that we would like to have to even extend even more our developer offering. So we know that there are developers who would like to make a bit of profit from their own very good software. And we would like to give a choice to them to do it. So it doesn't mean that when it says here copy protection, it doesn't mean that all software needs to be copy protection and it will be DRM protected. It's just a choice for you. So if you would like to have the possibility to own money on this platform, you can use the copy protection. You can put your software in the DRM. But if you don't want to do it, there's nobody who will force you to do it. So you can still distribute open software and it's more than welcomed. And there will be also a way to move between these two modes. And this can be done with a booting process and next slide will show how actually you can reach each of these modes. So the boot process is very high level. So not many details will start from a boot ROM which will first check integrity of the loader. And if integrity of the loader is okay, the loader can continue. So the loader starts to run and it will check the integrity of software image. And if it's software image is considered to be Nokia sign software image, then this second mode which I showed on the previous slide. So the mode which provides you DRM protection and access to application store which you know it called OV store. So you can load this mode because the kernel is fine, the software image is fine and it's Nokia sign software image. So let's now take a look on what happens when some of these components are not fine. So if the loader is, if integrity of the loader failed, then we can't allow this because we can't allow entrusted loader. So the device goes to reset so they're not allowing the change of the loader. But if integrity of software image failed, so there is still one question to be asked here. So if this device is SIM locked, so SIM locked here means that you for example buy the device from operator, usually it's less price, but you have to use it with the same, I don't know, I never tried to do it. So you probably have to use it for one year with some SIM card and it's locked to the SIM card. So if the device is SIM locked, then in picture it says that the other image is not allowed, but it's not up to us. So it depends on operator, on your contract with operator, maybe some local legislation in the country. So we really don't have any stand on it. So it's up to operator, but it's also up to you not to buy these devices from the operator. And just to mention this part, and then if device is not SIM locked, then we will allow to boot any unsigned kernel, any unsigned software image. There is only one step which will happen in between here with books saying restrict security functionality. So here, this step we need in order to protect things like for example DRM keys, because these keys can't be compromised and we need to disable these keys. And there are also a couple of small things which happened here, but after these things are done, you can load pretty much any, so you can load any unsigned software image. So the one you did and the one you compiled, so nothing prevents you to do it. So this is again high level with boot process. So let's move to access control part now. And here we got actually quite many questions already that there are many existing access control solutions in whole operating systems. And the question obviously of which we were asked is why are we doing our own access control here? And here's a slide which presents a bit of our reasoning why we decided to go this way. And first let's start what we had before. So what does our, what do the previous memory devices have? So the only thing we actually had it was the classical Unix access control model, which is a very user-centric model. So it was the threat, the threat model at the time when it was developed was there was number of users who were using the same PC and the goal was to separate data of these users with one, let's say, some bad user can't read your email, so can't read your private files. So this was a threat model when this classical Unix access control was created. And it was discretionary access control, so user and owner of the file could change the ownership of the file. And later the situation, we were trying to change this, let's say, extend the classical Unix access control by reducing, for example, Pozik's capabilities. And it was, I think, a very good idea, but they're not really in use now. So for example, root by default has all of them and others, users none. So kind of the concept is there, but it's not really used. And then our criteria, so my demo devices are mostly one user devices. So there's no actually need to protect one user from another user. So what, in the threat model now is that we would like to protect data between the processes because there's many applications that user installs. And the typical user, it doesn't really understand, and the program may look very nice and things that can be malicious. So users don't understand it. They may install malicious programs and they may try to steal the data and do other harmful things. So we would like to have access control, which is in process level. So we don't want to protect users from each other, but we would like to protect processes from each other. And also an important thing that we wanted to have, we didn't want to change the enforcement model, the current Linux enforcement model too much. So the goal was to make a minimal change to it. And of course things like good level of flexibility, granularity, some concept to be easy to understand even for a typical user, let's say not only for specialists. And we did a lot of analysis of current security frameworks and just access control frameworks and some of them are listed in the slide. And based on these analysis, I don't have time to explain it here. But actually we understood that there was no any of these frameworks which fit our criteria. And that's why we decided to go with our model. And I hope in the next slides I could explain it a bit. There's not much time, but let's try. So if we start from beginning, so what are the principles and key concepts we're using? So the first one is, let's say, very obvious principle. It's called the principle of list privilege. So the principle, it says, is that every application should be able to access only limited set of resources which are needed in order to accomplish its intended task. So not any possible task, intended task. And this is important in principle of list privileges. So you don't give more privileges to application with its needs to have in order to make its function. And I think it's very good principle and basic principle of many access control frameworks and security frameworks in general. And then we have this new concept which called here, protected resource. So before on my platform, all resources were available by default. So you call the IPI to get, let's say, a location of the current location of the user. And you get location back. But now some of these resources will be projected. So examples here, like for example, cellular functionality. So the reason to protect these resources, if the misuse of such resource could cause a harm, first of all, to user or to manufacturer of a device or various different scenarios. So let's consider it to be protected resource. We don't have any finalists. The work is real in progress. So they are not finished with face, whole with platform security. But they are on building it, they are in process of building it. And then each of these protected resource will be described with resource token. So resource token is like abstract name, abstract string describing this resource. And this will be a credential also for a process. So if a process would like to access our protected resource, it need a corresponding resource token in its credentials. And then our application also, from now it has to declare the resources it needs. And for this one, we will have this AGS manifest file. And I'm going to introduce in more details in the next slide. And also important thing about our security framework, there is no any security APIs by default. So you don't have to change your application in order to use some special security APIs. You can just use the standard one and benefit from security framework which is underneath. So couple of words about AGS manifest file. So in my platform, the software distribution is done inside Debian packages. And this AGS manifest file is an optional XML file inside the Debian package. So optional means that if you don't need any particular resources, you don't have to put it there. And then this file, as I said, declares needed resources and also provided resources because our models or resource token model is dynamic. So any new package it comes, it could introduce a new resource that it personally would like to control and protect. If it has some special, for example, database, its own special database which would like to protect, it can define a new resource for doing it. So it's not limited in any way with the concept. And then this file should be generated automatically by SDK, given a source code of your program so that you don't have to figure out actually what kind of resource tokens my program needs in order to function normally. And there is a couple of other stuff about this AGS manifest file. But I would like to introduce the last concept here, which is called application identifier. So this is the unique identifier of an application on a platform. It's supposed to preserve during whole lifetime of an application on the device. And it constructs it in a following way. So it from identify software source where this application came from, a package name and the application name in case there are many or binaries, many applications inside of the package. And we will use this concept a bit later. So it's quite important one. So still a couple of words about software distribution. So as I said, software comes inside Debian packages. And from device point of view, from application manager point of view, each package has a software source. So in classical way, it's based on repository signing. So classical Debian distribution way. It's the source of software repository. Or it can be also any virtual entity if we use the also going to support package signing. So it also be single developer or web page or somebody who has a key pair can sign a package. Also so as I said, that for in order to be recognized, this software source has to has an asymmetric key pair and public key needs to be known for device. And private key used to send the packages quite standard things. And on the device, each software source is assigned a trust level. And this trust level, we will basically mostly use for, let's say, we'll call it update rule. So if you have some package that came from our trusted source, very much trusted source, you should not be able to update this package with the source of less trust. Because it may be, it may be uses an attack against the user with users is nice update which is available under, through its, for example, application manager, which nice update of some system, very important system functionality that comes from some completely unknown, maybe even malicious source. So this is the way to prevent such an updates. And I will move forward. So I just security policy. So as I said in my first slide, with security policy, usually it's a control point of whole platform security. And this is our control point. And by the way, name I just doesn't, I know that there is somebody else who is using the same name. So I think it's just collision of names happened. So we don't have anything to do with that edges. So I just security policy. It contains in mapping between software sources and allowed credentials for that source. So there's example here below, but where it's like free software sources there. One is it knock up now one in my mother torque. So open source development portal. And then there is a list of resource tokens, which the source can potentially grant for an application. So if an application comes from the source, my mother torque, it can get user date can get access to user data or seller functionality if it requires it and it's just manifest file. And this policy can be changed for different set for different devices in order to provide a different security levels on the devices. So this policy can be very strict or very light weight and this how you can change the security policy. And now let's take a look on our installation time. So how the components interacting whichever and how actually the application it then gets the runtime credentials. So the application arrives to install together in the debit package together for ages manifest install or consult the agent security policy to get the allowed set of credentials for that software source because it can determine the source of this application. And then based on this I just manifest an agent security policy entry. It computes a rule. So used to the call intersection rule, which I will show in the next slide and it computes runtime credentials of a process and writes it to the file here called credential position list. So let's take a look on this intersection rule. So very easy. So we have ages manifest inside the package which declares what kind of application would like to access. So in the example on the right side, it's user data and seller. So application would like to get access to user data and seller functionality. And then it comes from the software source and the software source declares what kind of credentials this application can get if it arrives, if it was certified by that software source. And an example here, there is user data and location. So an advantage result credentials set result runtime credentials set here for the example contains only user data. And this is because it can get the seller, it requested the seller here and I just manifest, but it can't get it because the software source, this software source can't grant this resource. It doesn't have enough trust to grant this resource. And it also doesn't get location because it simply didn't request for location. So didn't say and I just manifest what it needs location. And this result credential set is actually the result runtime credential set which will be added to the process. And here's the runtime. So what happens when the application starts? So at the moment when it starts, we have a component called process credential assigner which goes to this credential position list. It finds the entry related to this particular application. It finds the credentials, this runtime credentials which are allowed for this application. And when it loads them to the process task structure in the form of supplementary group IDs. So this is how it's done technically. And then after process start to execute and it's always have this supplementary group IDs attached to it, credentials attached to it. And then the access control happens, for example, for file system it happens as before. So there's no any changes here. So there is file access control list in the file systems and various process credentials and there's no any changes. In case of D-Bus, in the process communication, we have a small patch to D-Bus D-Mon which they only, it's like small addition to D-Bus D-Mon. The only thing with addition does it allows the D-Bus D-Mon to take into consideration the supplementary group IDs. Because by default D-Bus D-Mon takes and when it makes its access control decision, it takes into consideration only user ID and group ID from static files. And then D-Bus D-Mon loads the process credentials and D-Bus policies, so D-Bus configuration file called D-Bus terminology. And then it can make an access control decision. And they're going to be also third way for application to make an access control. It can do it by itself. So it can call our leap-grids library. So we'll provide a special library to get credentials of another process. And then it could check for a special credentials it needs. And then it make a decision if you'd like to have this application accessing some IPI or get some particular data. And just to finish with access control part, I would like to explain shortly this shared libraries case. So what happens when the application try to load a shared library? So in the example here, we have an application which has two resource tokens and it's credentials, seller and user data. And we'd like to load library A. And we have like a bit of information here with suppose library A comes from very strange source. And this source is not unknown to device security policies. So it's not known. It's unknown source. And what happens? So the application sends a request to Kernel to load the library. Kernel redirected to our library checker component, which gets the credentials of application, seller and user data. It will determine the source of the library. And it will load the credentials that corresponding to that source. And then it will simply make sure that both sets are matching. And in this case, there is a mismatch because application has access to seller functionality, but the library source can't grant it. So unknown source can't grant it. And in this case, the loading of library fails. And this is needed from security point of view in order to prevent with our trusted processes, so it's very untrusted chart libraries because after the library is loaded to the process, it's in the process context, so it gets access to the same things that process gets. So very simple rule to avoid these things. And then in case it's a library B, which comes from the source which can grant seller and this example, the loading will succeed and everything is fine. So let's move on to the integrity protection now. So we have two main components here. First one is HSValidator. So this is the component which ensures the integrity of all executables and all different executables like binaries, libraries, scripts on the platform. So just a small picture how it works. So we have an application binary, which is about to be started. We have HSValidator, which will calculate the hash of this binary. And then it will get the reference hash for this binary from special storage. And the storage is populated during the installation of the corresponding package which brought this binary in. And it will try to match these hashes. And if everything is fine, so the hash is matched, then the binary can start to execute and everything is fine. But if there is a mismatch, the integrity protection policy will be taken into use. And now it's very simple. So currently if there is a mismatch, the binary is simply not allowed to be loaded. Because if the binary was modified on the device and not via software update, so just simply modified, there's probably something wrong with this binary. And then the storage of reference hashes is also needs to be, we need to protect the storage because it's a very important part of information. And for this we use the component with the HHS protected storage. It's in the next slide. So this component can be used and is used to ensure the integrity of data and configuration files. So I also get a small example here. So we have an application which has some data and configuration files. And suppose it would like to protect the integrity. The integrity. Yes. Can applications also put data on that protected storage? Yes, so it can be used for applications as well. It just, so I will explain, it's actually simply, it's not, it doesn't have any size. It simply allow, add you a signature or encryption over it. So it's just your data. It's not any particular size. So you just use the services to, we will consider it in a picture to encrypt or send the data. So you have this HHS protected storage, it's a library which you can use. So you can call the IPI of this library to kind of place these files in the protected storage if you would like to guarantee integrity. But in principle, it will just sign the data in its own way. And then every time you would like to check if your data is still okay, you can use a different IPI from the same library which like check integrity on a high level. And it will get the signature, it will verify the signature, and it will report you the status. So it will say if this integrity of this data is okay or not. And it's up to you what to do afterwards. So you can, even if it's integrity, it's not, if the file will be modified, maybe you will decide to use it anyway. But it's just a mechanism that you can use. And also this protected storage provide you not only integrity protection, but also encryption. So it could provide you, so you can use it to store securely the files which you would like to encrypt even. And this even survives the offline attacks. So it's really encryption here. And just to finish, I think I have a couple of minutes left. Let's move to our IPC communication. So yes. Pardon? So technically it's how on the disk that's encrypted? Yeah, it's simple file. You can open it and you can see what all stuff is encrypted where you can't even. So you can open it in normal way, but you will see that the content is encrypted. It doesn't make any sense. But the key will eventually be stored somewhere, right? The keys are stored in hardware. So you don't have to worry about it. But which hardware stores the key? We have this, but I didn't mention it in the first slide, but we call trusted execution environment. So this is the hardware and the embers which we are using. Why do you see the embers? For not mobile world, for PC world, there is a TPM. For mobile world, there is a different technology. But you don't have to worry about it. So you don't have to worry about key management in this case at all. That was the question, how you protect the file, how you protect the storage? But if you have a signature, so usually how the signature works, so there is a hash computed and we verify the signature of the file. But you don't have to really kind of call the special IPS to verify the signature. You have only one IPS, okay, check integrity. And this does all this cryptographic things in behind. And it comes out of the key security, the key is like storage, hardware, and the other part of it. Yeah, pretty much. So I think this is the last slide, so let's go over it. So here's another situation. You have an inter-process communication inside a device and you may be afraid that while you're transferring something, for example, over D-buzz, you get somebody kind of read the data. So here have two applications, which application one would like to send it to application two, or this kind of cloud thing, we call here potential entrusted zone, for example, it could be D-buzz or any other inter-process communication. And then what application one can do, they provide also library, we call it MIMO-CREAPT library, which it can ask this corresponding IPF from the library to sign this data in this case, and it will be, the data will be just returned together with signature. And then the data, when the signature can be transferred over, for example, a D-buzz or anything else, and then an application two can use the same library to check if this data really comes from application one. And again here, the good thing, you don't have to worry about any key management to establish a key, so to do everything is done again in hardware, all the key management is done, and there is very convenient IPAs to use to actually check these things. So the same could apply for encryption, so that you can encrypt some data using MIMO-CREAPT IPA, you can transfer the data over, again, example, D-buzz, and then another application could decrypt this data only if it possess some, or for example, resource token, mechanism of resource token is used here as well. So you can encrypt the data and say everybody who has user data, access to user data can decrypt this data, or everybody who has access to location data can decrypt this data, because I know that inside there is location data, so it's very convenient and it's very flexible. This is how you can also, with the usage of another library, you can secure your IPC communications. And short conclusions, so our goal is to open source most of our security framework, it's not only up to us, it's coming from a company, but we'll try our best. And then they actually already created a public project, it's called MIMO-6 platform security, and you can find it in MIMO-tourist.org. So we already have one repository under there, it hosts Libcrets library, so you can go check it out and start watching it. We really hope that we will add more repositories very soon. And at the end of the presentation and later I can answer any questions you have. And the main thing while we're here, because we would really like to get feedback from you and your opinions about our security framework, because it's the only way to get it better, so we won't get it better if we close it and say that nobody knows about it, and we try to make it very secure. So we don't believe in it, we don't believe in security, but in security. So we are here, we are talking about it, and we would like to get feedback for it. Thank you for your attention. So if there are questions. Yes. Very basic thing, it affects MIMO as we have it now. What happened to the principle of least surprise? I get this device, I want to install something. It's like, I get to install SSH and no can do, I need SU for it. So how do I set a password? I can find no information on that. And this is a principle of maximum surprise to a geek that you can't set up, you haven't got your own password. You mean the password for what? For? Well, so that I can run sudo. I have a box, I just need to set a password. I don't know actually about current devices. Sorry? I don't know about current, you mean that when you got this device, you would not be able to run it as a route or? Yes, I mean I have to install a package called extras and get a root shell on it, which means I've got a password as route, no security. No, but I think they're going to work on it so that it will be protected. To a geek that says I've got no security on here. I don't know much about the previous devices. I don't really work even for these kind of devices. I guess you're speaking about MIMO5 release. So I don't even, I can't even say anything about that one. I don't even work for that one. Sorry. Any other questions? Two questions. You had the access control service was based on the software source, on the repository. Is it also more fine-grained? I mean if there's a repository with solutions program that I want to accept data that I have another tool that I want to access my data, it's kind of useless to only be able to set the global for that one more repository and not program. Is there more time for that? But access control is not per repository, so it's really per program on the device. So the repository, the mechanism is a way that, so the, the, the, the, the, the, the the, the, the, the, the application of the device has its runtime credentials. So for example, access to the, some private access to user data access to location. But there is a control mechanism. How he gets, so for example, if it comes from very untrusted source, some source which there's no reputation whatsoever and don't trust this source, then it won't be able to get actually are, it can ask for many things and just manifest file, but it won't be able to get them during runtime. Did I misunderstood that source, this means repository or does it mean something else? It can mean a repository in a classical way. It can mean also, what I said, we're going to support package signing. So it can also mean that it's really prepared whenever who has a key pair. So. And the other thing you're example I had is that the FPC was talking about the resources that the application can address. I guess you also control which resources it can offer before you said which program can also offer. No, actually, so the application can, the package can provide a new resource. It will be, it can't provide some generic resource. So it can overwrite the current resource, but it can provide a known resource. It will be the kind of the space name will be kind of local to package so that we don't, it doesn't conflict with memory resources, but it can provide any resource. There's no actually restrictions in that one. Yes. When a file is in the protected store mode, does that happen in a performance impact? Because we have databases quite large with a lot of metadata. The speaker bytes in size are not very, have to be very fast. And yet our database probably going to have to be encrypted somewhere along for at least a large portion of the data. So I wonder about performance impact. There's a single line database. So this protected storage, which is going to be encrypted varies. So it's probably should not be used for the database cases because the database, so they are using hardware for their hardware accelerators to speed up the process. So it's, it's actually quite fast, but for database cases when you need to access like very often the database, it's probably not the best solution. So they're actually working on one more solution to, they're working on better solution for special for that cases. I hope they can update on this one soon. Yes. When does the user come into the picture? Is the user ever asked, do you really want to do that? You're asking about user prompting. So I don't know. I can't really comment on this one in case we will have it or not yet. So we have to wait a bit. So we, it's really working with progress now and the current thing that I'm presenting hits things that we already decided to do. I have a different question. What about side channel attacks? I mean you have very trusted processes running in parallel with very untrusted ones on the same device, on the same chip. I mean if I can measure various things, I might be able to get secret visa just by measuring. This can happen even over the next. Yes. So I'm not a hardware person. So I understand what you're talking about with side channel attacks, but I think we have hardware persons who knows about it. You're not talking even about offline attacks, but I get the device and I'm trying to take the keys out of the TPM. I'm talking really about the two processes running on the same machine and mori-con each other. And just by that they might be able to find things about themselves. I understand the only problem with that really, I'm not a hardware person. I don't know Janne if you can comment where to add one. I cannot say that such an attack is generally ignored. There are no tools to them to get involved. Well then Janne, I didn't sayga question. I think the best of this trust is. Okay, have a question. Would I be able to still make the package after privileges? I mean, I'm really convinced that the package is not equal because it's my own package. Would I be able to convince the package manager and become an everything? What do you mean to install your own package? Yes, we'll each have a privilege of one. Okay, we should be very careful about each and every privilege. So, I think that the privilege is that you have to actually, in order to get it, you have to be very, very trusted. And I'm not the one, I'm just a technical person. So, I don't know to whom these privileges will be given, like for example, DRM privilege. So, this is very sensitive privilege you'd have to protect. But in any case, for example, I have my motor torque side. So, my very short repository is there. We're going to have quite high trust level probably. Again, I don't know. I'm not the one who defining these policies. So, I'm presenting the framework who actually can do many things. I'm not the one who will decide. But I think in my motor torque, you should be able to do this. Yeah. So, will I be able to say modify the list of the trust sign in the source? Because I mean, it's my advice after all, right? So, am I going to change the decision to be, the decision to talk to my... Yeah, I understand. So, if you go to this, whenever presenting these two modes at the beginning, so if you go to this first mode, you're allowed to do everything. You're allowed to modify the security policy. You're allowed to create your own... You're allowed to trust, I don't know, maybe your friend repository the most, and then you say that, no, I don't trust with... And something like this. But in that mode. Yes. Okay, can I explain that? If he goes to that mode, will my encrypted files be gone from his device? So, if you go between the modes, so the encryption is... So, this is one thing we have to... It's nice to be encrypted for sure. So, a source that doesn't want somebody who is not trusted to look at the data. So, if you had some data encrypted using this, for example, project storage in this first mode, which is both like, shipped with DRM things, when you move to open mode, this won't be able to do encrypted data because they don't have any control of the kernel and they can't actually preserve, to guarantee anything. So, this is just a, like, the thing. But you can still, in that mode, use the encryption and then it will be different encryption. The keys are available. Yes. So, this key is really valuable. How do I back them up? No. So, the key is bound to the device. So, you can't back them up because you can't actually transfer them between devices. The device is dead. They are a little more like that. There is a project in MIMO, which is called Backup Service, which will be able to back up your data in very complicated projects, or complicated process, how it will be done. So, you will be able to back up your data, but not the keys. The data is not useful to me, but I have to keep track of it. No, but the keys... No, the keys are... No, the data would be probably... I don't know how it will work again. I'm not from there, but it probably will be encrypted and encrypted in some different keys and then pushed back up, for example. But then, to give note, yeah, my data, right? No. Or, I'll say a third part. Yeah. But I have to give away my data. It's not gonna be... But it's your choice to use it or not to use it. You don't have to use it when with encryption service. I feel like I'm five years ago, because this platform, as I understand it, and as a professional show, is functionally pretty much equivalent to DPM in those aspects, so this DPM has been dramatically standardized and dejected by it. So, my question is, to turn this into some form of constructive question, rather than a random question, I'm not sure what I would like it to do. Do you expect it to be competitive with version three of the DPLs, which could prevent exactly this kind of platform, and there's no competition to any of the discussion that has happened in the community regarding DPLs, which are formulated in the DPLs. So, do you expect it to be competitive or do you expect it to be in the current DPLs? So, my am currently is DPL two, and I don't have any... I'm not the one who is even deciding these things, but my am currently is DPL two. And that's why the kernel of DPL two I will say that one. So, I think... Yes. I just want to say one last slide. I think it's the good loader... Okay....checking if... So, my am on check is the......fifth of this one. Hmm? My am on check is the good loader is from Naki. I understand that. Yeah. I don't know. For me, I'm not familiar with my amour, but for me, my amour is like a small PC, and I will be quite upset if a thing, but would check if the loader is from thing, but... And... Yes, we have this one. So, what are your concern about? I would like to change the loader. For... And... Because many have a OS operating system that this loader is unloading, I wouldn't be......not about the loader, but the loader is a certain system... So, I would like to put a different operating system on this device. No, I would at least load it, because maybe some OS has some needs, for example. But in this... This loader maybe doesn't load my OS, and I want to change this loader. And in the NPC, you can change a loader, but not in the amour. It's a bit confusing. You can have a loader there on that, on such a free lift, if you like. I can launch another loader. No? Yeah, I understand. I want to launch a loader for long time OS. But there should be an enforcement point for us. I mean, there should be a point where we'll... Actually, we'll make decisions here, and we have to keep at least something... Yeah, I mean, why... In all PCs, the... The... The... The loader doesn't import the loader, but not the... The loader needs to import the loader. But if you can get still your own loader, like on top, why do you want to get rid of this loader? Why not? That's probably not a good reason enough yet. You can call me, but you can consider it like you buy a... Yeah. Yeah. Still, why do you want to send a loader in your thing, but as well as in your company? Okay. In your case, get ready. I'm afraid I have to finish for now, but I will be available, and together with my colleague, will be available today, the whole day for questions. But I think I have to finish now. Thank you.
Amour 6 release. And this presentation is used to protect the entire software platform. So encryption of user data or your private data for that you for example buy the device from its needs to have in order to make its function. manufacturer of a device or various different file. And I'm going to introduce in more details the way to prevent such an updates. And I will would like to access. So in the example on the is used to ensure the integrity of data and would like to protect the integrity. The environment. So this is the hardware and the the, the, the, the, the application of the device