 I think it's already a bit after two, so good afternoon to everybody, and I hope everybody had a nice lunch, and this is, I think, the first session for the security, the first talk of the security session, and my name is Elena Reshitova, and I'm coming from Nokia, my platform, and I don't know if many of you are familiar with this N900 device, so this is the device which runs open source development platform, the name is Mayamur, I guess there is even a competition where you can get some of these devices today, and I'm working for platform security in Mayamur, and the new platform security which is coming for Mayamur 6 release, and this presentation is supposed to give a short overview about Mayamur platform security, and let's see how much time we have, I would like also to leave a 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 two different device modes of operation for Mayamur 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 our 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's in the slide it says that it 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 are 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 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 we need to protect integrity, in this case it's integrity of binaries executable, so configuration data files, so everything we would like to be sure that it was not modified during the lifetime of a device, of course authorized modification allowed, but non-authorized or not, and when the access control very known thing in security frameworks, so who is allowed to access what and why and so on, and very last one is privacy protection, so here it mostly means the encryption, 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 these 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 it 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, but it's the needed security level, so this is really just a couple of words put to explain what is platform security, and so now let's move to the interesting part, so 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 very 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 case, 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, they probably will come up with interesting names after, but this mode of device operation is the same mode as we used to have on previous memory releases, so for example in this device runs M5 release, so you can do whenever you want with the device, you can compile, build your own kernel, you can run your own kernel, you can make any low 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, which I 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 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 into DRM, but if you don't want to do it, there is 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 room, which will first check integrity of a loader, and if integrity of a 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, when this second mode, which I showed on the previous slide, so the mode with which provides your DRM protection and like access to application store, which in Nokia called Ovi 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 the integrity of the loader failed, then we can't allow this because we can't allow untrusted loader, so the device goes to reset, so they're not allowing the change of the loader, but if the integrity of software image failed, so there is still one question that needs to be asked here, so if this device is Seamlocked, so Seamlocked 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 Seam cart and it's locked to the Seam cart, so if the device is Seamlocked, 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, so, but just to mention this part, and then if device is not Seamlocked, then we will allow to boot any unsigned kernel, any unsigned software image, there is only one step which will happen 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 of the boot process, so let's move to access control part now, and here we got actually quite many questions already that were existing, there are many existing access control solutions in whole, let's say 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, what do the previous memo 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 that time when it was developed was there was a number of users 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 file, 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 producing, for example, POSIX capabilities, and it was, I think, a good idea, but they're not really in use now, so, for example, root by default has all of them and others users, so the concept is there, but it's not really used, and then our criteria, so memo devices are mostly one-user devices, so there's no actually need to protect one user from another user, so what, and 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, it 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 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 root level of flexibility, granularity, some concept that would 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 this analysis, I don't have time to explain it here, we actually 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 whatever principles and key concept we're using, so the first one is, let's say, very obvious principle, called the principle of list privilege, so the principle it says says that every application should be able to access only a limited set of resources which are needed in order to accomplish its intended task, so not any possible intended task, and this is important in the 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 is called here, protected resource, so before on MIMO 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 can get location back, but now some of these resources will be projected, so for example here, for example, cellular functionality, so the reason to project these resources is that if the misuse of such resource could cause a harm, first of all to a user or to a manufacturer of a device or various different scenarios, so let's consider it to be protected resource, we don't have any final lists, the work is real in progress, so they're not finished with this whole this platform security, but they're on building it, when a 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, so and for this one we will have this edges manifest file, and I'm going to introduce in more details in the next slide, and also important thing about our security framework, but there is no any security IPIs by default, so you don't have to change your application in order to use some special security IPIs, you can just use the standard one and benefit from security framework which is underneath, so couple of words about edges manifest file, so in my platform the software distribution is done inside Debian packages, so and this edges 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 like 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 couple of other stuff about this edges manifest file, but I would like to introduce the last concept here, it's called application identifier, so this is the unique identifier of an application in a platform, it's supposed to preserve during whole lifetime of an application on the device and it constructed in a falling way, so it from identifier software source where this application came from, a package name and the application name, in case there are many or binaries many applications inside 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 when it's based on repository signing, so classical Debian distribution way, it's the source's software repository, or it can be also any virtual entity if we used we're 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 an asymmetric key pair and public key needs to be known for device, and a private key used to sign the package is 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 but you can't, 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 used as an attack against the user, but users use nice update which is available under, for example application manager, which nice update of some system, very important system functionality, which comes from some completely unknown maybe even malicious source, so this is the way to prevent such and 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 iGIS doesn't, I know that there is somebody else who's using the same name, so I think it's just collision of names happened, so we don't have anything to do with that iGIS, so iGIS security policy, it contains a mapping between software sources and a lowered credentials for that source, so there's an example here below, but there is like three software sources there, one is Knockup, now one is Miami.org, so open source development portal, and then there is a list of our resource tokens which the source can potentially grant for an application, so if an application comes from the source Miami.org it can get user data, can get access to user data or cellular functionality, if it requires it in its iGIS 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 lightweight, and this is 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 installer together, in the Debian package together for iGIS manifest, install or consult the iGIS security policy to get the allowed a set of credentials for that software source, because it can determine the source of this application, and then based on this iGIS manifest and iGIS security policy entry, it computes a rule, so used the call intersection rule, which I will show on the next slide, and it computes the 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 iGIS manifest inside the package, which declares what kind of application would like to access, so in the example on the right side there is it's user data and cellular, so application would like to get the access to user data and cellular 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 the 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 cellular, it requested the cellular, here in iGIS 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 it didn't say in iGIS manifest that it needs location, and this result credentials 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 ventry related to this particular application, it finds the credentials with runtime credentials, which are allowed for this application, and when it loads them to the process task structure in a 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's IDs attached to it, or 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 debuts, in the process communication we have a small patch to a debuts daemon, which the only it's like small addition to debuts daemon, the only thing with addition does, it allows the debuts daemon to take into consideration the supplementary group's IDs, because by default debuts daemon takes and when it makes its access control decision, it takes into consideration only user ID and group ID from static files, and then so debuts daemon loads the process credentials and debuts policies, so debuts configuration file, it's in debuts terminology, and then it can make an access control decision, and they're going to be also a third way for application to make an access control, it can do it by itself, so it can call our leap creates 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 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 in its credentials, seller and user data, and would like to load library A, and we have like a bit of information here that suppose library A comes from very strange source, and this source is not unknown to device security policy, so it's not known, it's unknown source, and what happens, so the application sends a request to kernel to load a library, kernel redirected to our library checker component, which will get 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 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 that our trusted processes loads 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 when in case it's a library B, which comes from the source which can grant seller in this example, the loading will succeed and everything is fine, so let's move on to the integrity protection now, so we have the two main components here, first one is Hs valet data, 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 Hs valet data, which will calculate the hash over 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 hashes match, 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 the software update, so just simply modified, it's probably something wrong with this binary, and then the storage of reference hashes, it also needs to be, we need to protect the storage, because it's a very important part of information, and for these we use the component with called Hs 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 or configuration files, and suppose it would like to protect the integrity, the integrity, yes, yes, so it can be used by applications as well, it just so I will explain, it's actually simply, it's not, it doesn't have any size, it simply allows 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'll consider it in a picture to encrypt or send the data, so you have this, I just protected storage APIs, it's a library which you can use, so you can call the IPI of this library to kind of place these files in 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 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 was, 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 provides you not only integrity protection, but also encryption, so it provides you, so you can use it to store or securely the files which you would like to encrypt them, 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 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, the keys are stored in hardware, so you don't have to worry about it, we have this, but I didn't mention in the first slide that we call trusted execution environment, so this is the hardware enables which we are using, or for not mobile word for a PC word there is a TPM, for mobile word 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, but if you have a signature, so usually how the signature works, so you, 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, yeah pretty much, so I think this is the last my 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-Bus, you'd get somebody kind of read the data, so here have two applications which application one would like to have some data, it would like to send it to application two, or this kind of cloud thing, we'd call here potential untrusted zone, for example it could be D-Bus or any other inter-process communication, and then are, what application one can do, they provide also library, we'd call MIMO creeped 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 D-Bus 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's very convenient IPIs to use to actually check these things, so the same could apply for encryption, so that you can encrypt some data using MIMO creeped IPI, you can transfer the data over the, again, example D-Bus, 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 save it, 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, with 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 we actually already created a public project, which calls MIMO 6 platform security, and you can find it in MIMO tutorials.org, so we already have one repository under there, which hosts LeapGrid's library, so you can go check it out and start watching it, we really hope that we will add more repositories very soon, and again at the end of the presentation and later I can answer any questions you have, and the main thing while we are here, because we would really like to get a 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 like very secure, so we don't believe in it, we don't believe in security, but security, so we are here, we are talking about it, and we would like to get feedback for it, and 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 do install something on it, so I apt get 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 haven't got your own password. You mean the password for what, for? Well, so that I can run sudo out of the 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 will 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 have a password that's root, no security. No, but I think we are going to work on it, so that it will be protected. I've got no security on here. I don't know much about the previous devices, I don't really work even for this kind of device, so I guess you are 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? 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 application on the device has its runtime credentials, so that for example access to the, some private access to user data, access to location, but there is a control mechanism how it gets, so for example if it comes from very untrusted source, some source which there is no reputation whatsoever when you don't trust the source, then it won't be able to get actually, it can ask for many things and say just manifest file, but it won't be able to get them during runtime. So it can mean a repository in a classical way, it can mean also what I said, we are going to support package signing, so it can also mean that it's really prepared whenever who has a key pair. So 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 new resource, it will be the kind of the, the space name will be kind of local to package, so that we don't, it doesn't conflict with generic resources, but it can provide any resource, there's no actually restrictions on that one, yes. So with protected storage, which is going to be encrypted varies, so it probably should not be used for the database cases, because the database, so we are using hardware for the hardware accelerators to speed up the process, so 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 solutions, especially for that cases. I hope they can update on this one soon. Yes, you're asking about user prompting, so I don't know, I can't really comment on this one in case we'll have it or not yet, so we have to wait a bit, so it's really working with progress now and the current thing that I'm presenting, it's things that we already decided to do. It's on the same device, on the same chip, I mean if I can measure various things, I might be able to get a secret piece, but this can happen even over there? 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. We're not talking yet. I understand the only problem with, I really am not a hardware person, I don't know, Jan, if you can comment on that one. Generally, the process separation is trusty. Okay, I have a question. Would I be able to still make the package after privileges? I mean, if I'm really convinced that the package is not available, it feels like it's my own package, would I be able to convince the package manager to return on everything like it isn't? What do you mean, to install your own package? Yes. Okay, we should be very careful about each and every privilege, there will be privileges with, 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 a very sensitive privilege you'd have to protect, but in any cases, for example, you have MIMO.org site, so my very sure repository is where, 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, but I'm not the one who will decide like, but I think in MIMO.org you should be able to do this. 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, when you allow 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 when you say that, no, I don't trust, and something like this, but in that mode, yes. So if you go between the modes, so the encryption is our, so this is one thing we have to, so if you had some data encrypted using this, for example, projector 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 decrypt the data because we don't have any control of the kernel and we can't actually preserve, to guarantee anything, so this is just 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. 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. There is a project in MIMO, which was called Backup Service, which will be able to back up your data in various complicated projects or complicated process, how it will be done, so you will be able to back up your data, but not the keys. 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 decrypted and encrypted in some different keys and then pushed back up, for example. But it's your choice to use it or not to use it, you don't have to use it in this encryption service. So MIMO currently is DPL2 and I'm not the one who is even deciding these things, but MIMO currently is DPL2. So what are you concerned about? So we'd like to put a different operating system on this device. But there should be an enforcement point for us, I mean, there should be a point where we actually will make decisions here and we have to keep at least something, but if you can get still your own loader, like on top, why do you want to get rid of this loader? That's probably not a good reason enough yet. 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. Thank you.