So, what I actually didn't have any real agenda to talk about, I 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 OpenSC 2015, but in fact actually it doesn't have much to do with OpenSC as a

project, but more about the whole ecosystem, how the things could look like in 2015, or is the future bright or is the future dark.

The title page 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, I come from a stone that used to be a Soviet country that used to love the five year plans. We'll just take a look back when I started to work with OpenSC, it was 2004 or 2005 or something like that, and 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 check out to see how the code looked back in 2005, and at the end

of 2005, not in the beginning unfortunately, there were 17 different card writers, like support for roughly 17 different cards. Right now the number is 30. Well, it's pretty nice, almost double. When you take into account that some

of the cards are actually already long-paid, 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 if it works. It seems actually a huge number, like 30 different card writers, but you know, it's a pretty old project, it

started in 2001 I think, and one of the problems of the many card writers has been a lack of standardization. All the card writers implement kind of a proprietary reverse engineer, something similar, a common interface, but for

example, the Estonian ID card, which I worked most, was one of the cards that was set in stone before package test 15 even existed, which means there's no relation to package test 15 in that card.

ESOL 71650, which is something like ESOL standard for package test 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. When you take JavaCards for example, we have a JavaCard 3 specification for a few years already,

but none of the card vendors actually implement or provide you with cards that provide JavaCard 3 compatibility. We have now the European citizen card, there's the PV 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, that we won't have so many new card writers because we have standards, we should 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 EAD 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 also from 2004 or 2005.

There's Spain, Italy, Portugal, there's a new card coming in Germany, there's something in, you know, 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 pinpad reader, they existed. Even I think some of the models are still sold, but there was no real standard for using pinpads. Yes, there was, but the standard, the CT API is now long gone, because it wasn't any good.

There wasn't even CCID. I don't know, again, the dates exactly, but I think it was also 2000 something, like 4, when the CCID matured. Right now all the smart readers you can buy anywhere, most of them are CCID. Do they support extended APDUs as well?

That's another issue. For example, extended APDUs is one thing I forgot that is also very important in the products of smart cards. We have pinpads. In 2004, there was some industry consortium providing some

kind of a specification that's now part of the PCSC breadth 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 machine, it's proved very open.

But there are standards, which is really, really nice. In 2004, for example, there was Mac OS X, 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 real bias for cross-platform smart card use.

Well, talking about OS X, before the important client platforms were Linux and Windows, but then came OS X, which is now, I don't know, depending on the country, from a few percent to 10 percent, something like that.

It's kind of important. Luckily, it's Unix, so we can use some of the tools, even though Apple screws up the open source very often, very heavily. It's still better than Windows in some situations.

During the past five years, things like platform plugins that plug into the overall structure or overall services of the platform, like Windows and Mac OS X, have emerged. That's something that has been discussed heavily here today, is the Deco S11, which is like

the big platform API, the big platform plugin for Linux, because there is no common framework. There is no such thing like Win32 API or like crypto API in Windows or token in Mac OS X that all the same nature applications use.

In Mac OS X, you don't have nature applications. You can take a fight and ignore them. But that's not the point. The point is that there is no cryptographic platform. There is just a set of libraries you can use. One other thing I noticed is devaluation or maybe detagmentation of certificates.

Usually five years ago, certificates were all good, so the padlock icon, yes, secure. But now what they tell you, unless you see the green bar, and not just green bar, but the special light green, be afraid, be very afraid. Drop the keyboard and run away.

Just something to think about. And from a smart card point of view, the reason why there were so many card drivers, there are so many card drivers in OpenSC, 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 like huge

card vendors have, maybe even card vendors, but the silicon vendors offer every kind of stuff. But the application vendors have settled on Java cards as the open platform, which means you can have your PIV application and you can choose your vendor for the card. Again, something to think about.

So, what is happening in five years in the world of smart cards and open source software? Well, we can try to develop the open source software just with, how 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 inevitably. We can't, we can't avoid that. The most obvious is new algorithms. Right now, when you take any kind of cryptographic software, what do you mean? Like, public key means RSA.

Like, OpenSSA is the kind of the one that made up the, or the one that tried out the open source cryptographic software. I think it was one month ago when 5.7 version was announced to the ECDCA support. In a few years, when you take the different government or industry recommendations for new algorithms, we need to deal with it.

We need to deal with elliptic curves, we need to deal with, other than MD5s, long tail, other than SHA-1, there will be SHA-3 in five years. The recommendations for RSA keys, like 2048 bits should be the standard since, I think, last year already.

So, once again, from a smart card technical perspective, it brings us to the problem of extended APDUs. Because the buff version of the smart card will be longer than the short APDU 255 byte limit.

We're going to have to hide one or two more bytes somewhere. So, it brings again a lot of trouble to the primer writers, but it's something application developers should really heavily think about.

You know, RSA will 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 is BOSS, for example, another interesting protocol to think about.

So, in the next five years, even more people will have the ID cards that were starting 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? Or at least there will be a much further audience for different applications. And we need to think about it. How can we accommodate all the people?

How can I make the software so usable that actually your grandmothers and brothers and brothers are willing to say that you're trying to get smart cards? Like, you know, in a corporate environment or a hacker environment that you will have every European citizen, most of them will have some kind of smart card they can use, and probably the government will invent ways to use it.

So, again, something we can't avoid is, we can talk about package SC11, but the open source is kind of a broader thing than just the Linux world. So open source exists, for example, OpenSC works on Windows, it works on Mac OS 6.

These are closed platforms, proprietary. Even though Mac OS 6 claims that it's open source, and for example the software used to build the native plugin for Mac OS 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 scratch your head, what the fuck is this? No one asks any kind of questions. It's not open source. And native applications, do we like it or not, we use something that works smoothly for the desktop experience.

We 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 in Windows, doesn't use the built-in certificate store and the built-in drive in Windows, that's kind of a legacy. That's a very bad choice by Firefox guys.

When you take the new, my favorite browser, Chrome or Chromium, it works with crypto API on Windows, a very smooth experience. It works with the native APIs on Mac OS 6, the best browser because software just sucks.

It does some stupid things, certificate selection, it's not really usable. One week ago or a few days ago, the Linux version of Chromium proved actual support for smart cards. You can use, it asks for a payment. Florian didn't use it to do that. The native builds were flawlessly much better than Firefox. Good smart person.

Through package S11 because there is no platform for 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 it can do on Linux because there is no other option than package S11, even though it's not the best, as I said before.

So what we'll also probably continue is the debate whether smart cards and any kind of hardware cryptography is like a three-letter organization, multi-million dollar investment, hidden expense and so on, or 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. And other things, the mid-crigger, you know, the mid-criggers, there's a saying in Estonia that there are porridge monkeys in mid-criggers and everything is, you know, thinking, shining, closing. Actually there's something that's missing, I had a few more lines I didn't need to invent them.

First of all, due to the standards, hopefully in five years we will not see another similar explosion of cards writers in OpenSC, you'll see actually that the number shrinks because we're going to have standard interfaces, we'll have more standards, more card vendors

and companies actually stick to standards for the issue of cards, performance and so on. We'll have a fewer, but more supportive, more supportive smart cards. I'm sorry actually, I'm going to do a switch now.

The perfect fusion would be that we'll need to grow usability. This has been demonstrated over and over again that the user experience of any kind of user problem of security is you have to make a balance between the

the hardest 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 become, or will it remain, so to say, big guy in business, if we want to become a commodity,

well I think everybody would like to see you need to become usable somehow. So the usability is basically my wet dream. And what the usability means, one of the biggest problems which has also been discussed before is the enrollment or the card management or the personalization or initialization.

Well if you get a card from a government or your company or something, you don't really care about it. But if you want to make crypto usable so that you can use it in your own embedded 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 with SSH you will actually authenticate against the Harvard token in the wireless browser. You 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 these fine things that Linux has. Well Linux is famous for frameworks. So we want to create one again that which is the right one, 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 reference, something like that. So the diversity is nice. I don't think it should be dropped, but you need to get interoperability. And then the application is written in a new TLS.

Good work with the same part, and then the application is written in an open SSL, with open SSL in a very similar way. So yeah, that means accessing objects. That means like everyday use, when you go to some website and you need to authenticate, you need to authenticate to work.

Like, singularly, because you could have the option to choose something. And the other thing is that what most of the SSL libraries actually do, and what Steph pointed out, that the way to distribute or talk about trust, I'll put it in small tricks

because it means different things. Important points here are like setting the trust anchors or something like that. It needs to be communicated between different applications to work it out. So the proposal is what Steph said about making

pegasus libraries usable across applications. That's something really, really great. And the tough task to do is integrating with proprietary platforms. Maybe not really that interesting to the open source developers who work with Linux, but for an open SC as a project

which should bring the open source promise to everyone without any discrimination on the platform. This is a tough task because, for example, for Micro6, we depend on the Apple guys, how they do their stuff when Steve Jobs wanted to do an announcement on the stage.

But it 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 Windows, in Windows 7, for example,

you can load the open SC, the open source software. But, for example, you cannot do it because Windows policy disallows open source auto-discovered drivers. So, again, something to think about. And another tough task to do is to actually move the open source to the other side of the chip interface.

Right now, all the software talks about how to make use of the card, but actually you can put the open source software into the card, and there is no solid solution for it. There isn't a solid child card right now. There must be one who came here all alone

and not give up the game model. Basically, that's it. So the tough task is the consolidation, which is the damn 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're getting everything,

versus interoperability, which is difficult. This is something Linux has this card being quite good at. For example, when you take GNOME versus Kali, there's this pre-desktop that kind of assesses the common things and the common tools and common APIs

that all the onboard projects and other projects can use to gain interoperability. So looking for interoperability in both practical and theoretical ways is the most tough task, in my opinion. Questions? I'm over my time limit.

Is there a meeting somewhere to eat afterwards? Yes. Actually, it's nine o'clock, and we're going to have two hours to spend. There are a few more places, I think three places, because one guy said he can't come,

and there were two or three places before. So if anybody wants to join us for an Italian... So should we finish the discussion so I can stop recording? Are you done? Okay, thank you very much.