 So, I actually didn't have any real agenda to really talk about, just wanted to see what they will evolve into and see what I can come to some kind of conclusions. Well, the topic of the talk should be like open to sea in 2015, but in fact it doesn't have much to do with open to sea as a project for more about the whole ecosystem, how the things look like in 2015, or you know, is the future bright or is the future dark? Well, the type of age is black like funerals, but actually it's not that bad. So, before trying to make any kind of plans or predictions for the next five years, a couple of months ago, and it used to be a so-get country, they used a lot of the five-year plans. Well, just take a look back when I started to work with open to sea it was 2004 or 2005 or something like that. And, you know, just to see what has happened during the past five years to maybe see some hints or insight into the future, things that might happen. So, just did a code checkout to see how the code looked back in 2005. And at the end of 2005, but in the beginning unfortunately, there were 17 different card drivers like support for roughly 17 different cards. Right now the number is 30, which is pretty nice, almost double. And we can take into account that some of the cards are actually already long dead. You know, many are in a state that there's gold, that there's actually no one with an actual card to test it, or no one actually knows it before it. It seems actually a huge number, like 30 different card drivers. But, you know, it's a pretty old project, it started in 2001, I think. And one of the problems of the many card drivers has been the lack of standardization. All the card drivers implement kind of a proprietary reverse engineer, something similar, common interface. But, for example, the Stoney ID card, which I work most, was one of the cards that was set in stone before back assistive T didn't even exist there, which means there's no relation to back assistive 15 in that card. ESOL 71615, which is something like ESOL standard for the back assistive 15, it also appeared in 2004 as a standard. But usually standards are either like documentation of existing reference implementations, or they set some kind of, you know, industry common views to stuff that actually isn't implemented. So when you take Java cards, for example, we have a Java card 3 specification for a few years already, but none of the card vendors actually implement, or, you know, provide you with cards that provide Java card 3 compatibility. We have now the European citizen card. There's the PVE standard in the United States. They all, like, describe the common interface to a card. So that's something that should maybe limit in the next five years, but we won't have so many new card drivers because we have standards which help it. We should have, like, standard drivers. During the past five years, I don't know the numbers, but several European Union member states and other countries have introduced EIG programs. They're all somewhat different, all are somewhat similar. For example, in Belgium, I think the project has been as long as five years, or from also from 2004 or 2005. There's Spain, Italy, Portugal, there's new card coming in Germany, there's something in other countries as well. But anyway, that's something that was set as some kind of policy decision that by 2010, there should be interoperability, for example, for digital signatures in the European Union. We're not there yet, as we saw from the presentation by someone. In the past five years, there's been kind of a huge standard stabilization in the system, APIs and standards that are used. Back in 2004, for example, there was, when you had a PIMPAD reader, they existed. Even I think some of the models are still sold, because there was no real standard for using PIMPADs. There was, but the standard, the CT API is now long gone because it wasn't very good. There wasn't even CCID. I don't know, again, the dates exactly, but I think it was also 2000 something, like four, when the CCID matured. Right now, all the smart readers you can buy anywhere, most of them are CCID. Do they support extended APNU or CCID as well? That's another issue. For example, extended APNU is one thing I forgot, but it's also very important in the products of smart cards. We have PIMPADs. In 2004, there was some industry consortium providing some kind of specification that's now part of the PCSC brief specification, which of course is not maybe the best specification because it has no public review, it has Windows guys doing it, which means, you know, when you have a big engine machine, it's proved very often. But there are standards, which is really, really nice. In 2004, for example, there was MacOS 6, but it didn't come with the PCSC framework. It appeared in OS X 10.4. But now it's included in the system. It's kind of the only reliable solution for cross-platform smart card users. Well, talking about OS X, that before, the important client platforms were Windows and Windows, but then came OS X, which is now, I don't know, depending on the country, for a few percent, ten percent, something like that. It's kind of important. Luckily, it's unique, so we can use some of the tools, even though Apple screws up the open source software very often, very heavily. It's still better than Windows in some situations. And during the past five years, things like platform clients that plug into the overall structure or overall services of the platform like Windows and MacOS 6 have emerged. That's something that has been discussed heavily here today, is the Tech Access 11, which is the platform API, the platform plug-in for Linux, because there is no common framework. There is no such thing like Mi 32 API or like Qt API or Windows or the token TV or MacOS 6, that all the, so to say, native applications use. In MacOS 6, you don't have, sorry, you don't have like, native applications. You can take a bite and ignore them or whatever you think, but that's not the point. The point is that there is no, like, cryptographic platform. There is just a set of libraries you can use. One other thing I noticed is the evaluation or maybe de-technization of certificates. You know, usually, five years ago, certificates were all good. So the padlock icon, yes, secure. But now, what does that tell you? Unless you see the green bar, and not just green bar, but doing a special, you know, like the green, you know, be afraid, be very afraid, drop the keyboard and run away. Just something to think about. And from the smart card point of view, the reason why there were so many car drivers, there are so many car drivers, and all you're going to see is that most of them target a specific card operating system. They target a specific common interface, proprietary, not documented, whatever. But with the rise of the different interface standards, like PIV and ECC, most, most, like, huge card vendors have, I don't think even card vendors, but the silicon vendors offer very good kind of stuff. But the application vendors have settled on Java cards as the open platform, which means you can, you know, have your PIV application, and you can choose your vendor for the card. Again, something to think about. So what has happened in five years in the world of smart cards and open source software? Well, we can try to develop the open source software just, you know, the, what do you call it, IVs, without looking anywhere what's happening, but it's not really a productive thing to do. So in the next five years, probably, not probably, but we're going to see things that will happen in evidence. We can't, we can't avoid that. The most obvious is new average. Right now, when you take any kind of proprietary software, what do you mean like public key means per se? Like, open as it says, the, kind of the one, the key of the, or the one side of the open source to wrap software. I think it was one month ago when 5.7 version was announced to the ECDCA support, the Liptic Curve PSA. In the next few years, we need to take the different government or industry recommendations for new average. We need to deal with it. We need to deal with the Liptic Curve. We need to deal with other than MD5, it's long dead, other than SHA-1, there would be SHA-3, or SHA-3. Yes, in five years. The recommendations for, let us say, keys, like 2,048 bits should be the standard since, I think, most of them already. So once again, from a smart technical perspective, it brings us to the problem of extended APDUs, because the both versions of smart drive will be longer than the short APDU 255 byte limit. It's going to have to hide one or two more bytes somewhere. So it brings again a lot of trouble to the private writers, but it's something application developers should really heavily think about. You know, let us say we run out of juice sometime, and we need to be prepared. We need to be prepared in our application designs, in protocols, in software stacks, and so on. And there's, for example, another interesting protocol to think about. So in the next five years, even more people will have the ID cards that were started to roll out in the last five years. Which means that even if the cards are out at the wallets of people, they don't maybe use it. They don't maybe use them because they don't have any kind of services or software to use them with. But if more and more people will have them, more and more people will think, how can I use it? Which means there will be much for their audience and we need to think about it. How can we accommodate other people? How can we make the software so usable that actually your grandmother's and brothers and brothers will say, how huge currently smart cards like, in a corporate environment or a hacker environment, that you will have every kind of every European citizen, most of them will have some kind of smart card they can use. And probably government will invent ways to use it. So again, something we can't avoid is, we can talk about Peket's S11, and the open source is kind of a broader thing than just the Linux world. So open source exists, for example, OpenSC works on Windows, for MacOS 6, and these are close platforms, proprietary. Even though MacOS 6 claims that it's open source, and for example the software we use to build the native plugin for MacOS 6, it's so to say open source, but it doesn't mean it works like open source. The next final release breaks everything. When you ask for support, there's no comments. When you look at code and you stretch it here, what the fuck is this? No one trust any kind of questions. It's not open source. And native applications, do we like it or not, we'll use something that works smooth before the desktop experience. We'll use Microsoft APIs. For example, the fact that the Starship or the flagship open source browser right now, Firefox, doesn't use, the Crypto API Windows doesn't use the built-in certificate store and the built-in drive-in windows. That's kind of, actually, that's a legacy. That's a very bad choice by Firefox guys. When you take the new, my favorite browser, Chrome or ChromeView, it works with Crypto API on Windows. Very smooth experience. It works with the native APIs on MacOS X, the best browser because software just sucks. It does some stupid things in certificate selection. It's not really usable. One week ago, or a few days ago, the Linux version of Chromium proved actual support for SmartParts. You can use it, it asked for a thing. Before it didn't use to do that, the night builds were flawlessly much better than Firefox. With SmartParts. Through back at S11 because there is no platform on Linux. Something we should think about. What I wanted to say is that Chromium is open source and it is doing the right thing. And it is doing the only thing you can do on Linux because there's no other option than the S11, even though it's not the best as I said before. So, what we'll also probably continue is the debate whether SmartParts and any kind of, you know, hard topography is like a freelancer organization with a million dollar investment you know, hidden and expensive and so on. Where it's a commodity for grandmothers, fathers, me and you, whoever. That's the thing, you know, for some of us it's a good way to make money and say it's so complicated it needs to be expensive, it needs to be very high level because it brings us more money. Oh, nothing here. Right. The other thing, the mid-ridder, you know, the mid-ridders, there's the same in Estonia that there are porridge monkeys and mid-ridders and everything is, you know, thinking shiny and cozy. Actually, something is missing. I had a few more lines I had between them. First of all, due to the standards, hopefully in five years we will not see another similar explosion of cart riders in open sea. You will see actually that the number shrinks because you're going to have standard interfaces. We have more standards, more car vendors and companies actually stick to standards for the issue of cars, performance, and so on. So we're going to have a fewer of more supported... More supported smart cars. I'm sorry, actually. We'll do a switch now. So the perfect future will be that we'll need to grow usability. This is to be demonstrated over and over again that the usage experience of any kind of the usual problem of security is you have to look at the balance between the harness of the security and the usability of the system. We need to grow usability somehow because if we want to win the debate, will it become a commodity or will it remain as so to say big iron business if we want to become commodity what I think everybody would like to see we need to become usable somehow. So the usability of the product is basically my wet ring. And what the usability means one of the these problems which has also been discussed before is the enrollment or the card management or the personalization or the initialization. Well, if you get a card from a government or your company or something they don't really care about it but if you want to like make crypto usable so that you can use it in your own invented environment you want to be able to personalize your own tokens or use some token for your home server to plug it into your wireless router and when you connect to SSH you will actually authenticate against the hardware token in the wireless browser. We need to make that somehow manageable. Diversity versus interoperability versus Yeah. Well the thing with Linux is that one of the tries to make the thing more homogeneous so to say is the Fedora Crypto Consolidation which takes the very easy road that you're going to use NSS you're going to be happy and you're going to have like all the fine things that Windows has. Well Linux is famous for playing wars so we want to create one again which is the right one with new TLS or open SSL or NSS or whatever I doubt it but I would like to choose I would like to choose based on my personal preference my maybe application register preference something like that so the diversity is nice I don't think it should be dropped but we need to get into interoperability and in other cases we can have new TLS could work with the same part and in other cases we can open SSL with open SSL in a very similar way so yeah that means accessing objects that means like every day you always when you go to some website you need to authenticate with a key and this authenticate to work like singularly but you could have the option to choose something and another thing is that the what most of the SSL libraries actually do and what is that very clearly pointed out that the way to distribute or even talk about trust I put it in small tricks because it means different things unfortunately policy or like setting the trust anchors or something like that it needs to be communicated with different applications that you are working out and actually the proposal is what Steph said about making package SSL that is usable across applications that's something really, really great and the tough task to do is integrating for private platforms maybe not really that interesting to the open source developers who work in Linux but for an open SD as a project which should bring the open source promise to everyone without any discrimination on the platform this is a tough task because you know for example for Maca6 we depend on the Apple guys how they do their stuff when the Steve Jobs want to do an announcement on the other stage they won't tell us anything with Windows for example it would be nice to have when you plug in a card that doesn't have any kind of vendor support vendor support in in Windows in Windows 7 for example as you could know the open SD the open source software but for example you cannot do it because Windows policy disallows open source auto discovered drivers so you get something to think about and another tough task to do is to actually move the open source to the other side of the the chip interface so right now all the software talks about how to make use of the card but actually you can put the open source into the card and there is no solid solution for for it there isn't a solid child card that would try it now the Moscow one the food came there all alone and not without the basically that's it so the tough task is the consolidation which is the time the easy path just saying that this is our policy which can be done in a closed project we're going to use this and we gain everything versus interoperability which is difficult this is something Linux says this card being quite good at for example when you say no versus Kali there's this free desktop that kind of assess the the common things and the common tools and common APIs all the all the goal projects and other projects are used to gain interoperability so looking at interoperability in both practical and theoretical ways is the most tough task in my opinion that's it questions I'm over my time with their meeting somewhere to eat afterwards yes there is actually it's 9 o'clock and we're going to have like two hours to spend so there are a few more places I think three places because one guy said he can come and there were two free places before so if anybody wants to join us we're Italian so should we finish the discussion so I can stop recording are you done? okay thank you very much