- Hi! Today's topic is RouterOS 7 certification management. We will start to dissect the shell, the edges, the capabilities of the system. Our guest is Attila again, who... - Hi! is probably the most knowledgeable of us all about this technology, and we'll try to chew our way through this topic together.
That's why we have the notebook and the introductory or reminder material before us so that we don't miss anything you might be curious about. So: certificate management: let's get started! MIKROTIK CERTIFICATE MANAGEMENT Where do we start? In relation to certificate management, we were talking here before the recording about some old stories, old experiences that we all probably learned in school or were beaten into our heads on some course, and some old grievances came up that we have had this solution and this technology with us for a very long time. In fact, it's about a standard of the International Telecommunications Association, The ITU. the ITU standard, x.509, and we're going to look at version 3 of that which the IETF mentions and documents in a slightly different way in a family of standards called PKI, or Private Key Infrastructure.
So the two are technically very close. But the point we're at today is that these two families of standards, it's actually starting to evolve into a framework. It has a lot of extension possibilities, a lot of flexibility, so it's not only specifically identity validation that we'll be talking about today, or identity validation is not the only thingwe can use it for, there are a lot of other procedures that can be conducted within this framework we have a lot of room for manoeuvre. We are actually here today and we are sitting around the table to see how this technology has been implemented in the RouterOS aspect and what we are getting from MikroTik? Yes. What is it out of the whole thing that this system supports? What's new here in terms of RouterOS 7 compared to what's been done before, and what it looked like inside RouterOS 6.
Okay, well, this identity verification thing is such a very serious problem. I'm sure everyone remembers the scene where Milla Jovovich says "Leeloo Dallas multipass" and she identified herself with that. Well, we would like to produce a similar digital identity on the network, because when there is any form of communication between two endpoints, it is important not only that others cannot observe the content of that communication, but also that the parties to the conversation can be sure that they are actually talking to who they want to talk to and can clearly identify themselves. What was that ancient solution we used the most before these complex certificates, these very complex verification methods could have created? Think about the possibility of using a common pre-shared key with WPA technology, for example. This is basically a dead simple, primitive method of saying that if we both have the same password and we say it out loud at the same time we realise that, well, yes, the other person knows it too, then we are probably in a group or a gang. It is the common signifier, the password.
Well, or we can also think that there is a communication, and if I encrypt that in one way, and if somebody else decrypts it in the same way then it will presumably be a meaningful communication. Of course, it is also important to note with that, that it can'be assumed that during an encrypted communication will be meaningful. since with these encryption systems we have a Ciphertext, and then it will end up as unencrypted content, (at least we assume), but there is no guarantee that it is indeed meaningful. So after the decyphering is done, both of us needs to know what the actual information if that we expect to be in there that we can validate it with.
because we can decypher anything out and it will be stupid at best. Yes, and in this key-sharing problem, there's also the classic school example that we talked about of how we can make it so that you have two people who can only be connected by one of these very, very gossipy postmen who can look into the mail, I don't know, like, opens the envelope over steam and read what's inside. And then how can this be done, so that the two of us can communicate reliably over this unreliable system, that we can be sure that the other side is who it really is. And to have exchanged important information, such as the key used for encryption in such a way that no third party has access to it.
And then we have this classic example, the locksmith example. What we know, the locksmith example. Imagine a medium. I would like to share information with Attila, between us the infinite world, the curious, the spies who want to intercept information. - Or perhaps to change the information. - Sure. Let's say we have a solution based on a shared secret.
I'm going to take this shared secret, I'd like to communicate with it, but I have to send it to it first somehow, but I have to send it in a way that I don't have to package the key with it. So what I'm going to do is I'm going to take my little box, put the shared secret that belongs to just the two of us and I'm going to put my little padlock on it, pull my key out of it and send it to the other side who gets it. That's right. The postman can't open it because he doesn't have a key. I can't open it because I don't have a key either. Well, what can I do? Okay, well, if I can't, at least he can't read it, so I'll lock it with my padlock, and now it will be a two-lock box that the postman will take back again.
He still can't unlock it because my key hangs on my neck, his key on his neck. - You get my box. - So now our box is doubly safe. It made it to me. What can I do?
Obviously I can't get my key in his padlock, it will probably not even fit. I have no better chance than to take my own lock off and send it back again. The postman still can't read it either, no matter how he tries to pry our box open. it now only has Attila's lock with his key on it. That's right, but once I have received it, I can take off my own padlock from it, and open the box and get the message from it, the secret only I was entitled to get. The shared secret.
And obviously, if you look at it, it's not particularly the most efficient thing from a communications point of view, that we're passing things back and forth to get from one place to another place and obviously you might have to do the same thing in reverse if you want to use a different kind of encryption method, or get a different kind of secret information to you through an untrusted channel like that but it can guarantee that nobody has access to the data along the way. But it has got through to me, and if we trust our own security procedures - which is also a separate issue apart from this whole story. I mean, how secure is our lock and how unbreakable or how unpickable. In practice, I think these analogies also apply to digital technologies that have been created today by very clever mathematicians in order to enforce or play out these analogies who are working on these algorithms and procedures for many years, decades.
Yes. They count the primes, with very long digits. And they generate all sorts of random numbers, and maybe these are actually the tiny aspects of these technologies or algorithms through which you can scratch around them a little bit. Either the random number generator is usually influenced, or the flaws or its awkwardness is exploited by the possible bad guys of such an algorithm, or they interfere in some way with this random number generation, with all kinds of variations with prime numbers. Yes. Or possible coding errors. If anything, - you could say that these algorithms are complicated, and then presumably there's complicated software code involved.
And there's this interesting formula that a lot of people know, E=MC2. Errors = more code squared. So the more code there is, the more likely there will be some kind of error.
That's right. And there have been examples of this before. Who had it, Sony? Sony? Well, that happened with an algorithm, that could be called very modern, which of course, - how does the world work? When you have a new algorithm like this, mathematicians prove it, derive it, implement it in some demonstration software, -... in a prototype... -... and then people come along and start writing code. Yes, and the first thing people say... ...the marketing people come along,
they carry around the new code in their bags, that it's unbreakable, it's a sure thing, and then the silicone is produced that can calculate it very quickly, interact with it, the big manufacturers implement it, and then the first thing that happens is that someone in this system says, "Oops". Here we have found something small. It's been done in many places. Yes, it has. It has. I remember there was a stunt with, I think, OpenSSL,
which was, well, it was accidental, but then it wasn't that accidental... Heartbleed, maybe? Yes, it was later, but there was an earlier one, where the number of possible variations was practically 2 on the power of 16 combinations, so it didn't mean that we had managed to recover the original, but we had managed to produce information equivalent to the original, and from then on the whole stunt became, well, such a pointless exercise, because any key that was generated with that could very well be replaced by another key among 65,535 variations. So even if the actual mathematical background was behind it, if the implementation was bad, then the whole thing was practically vulnerable. That's why these are important, so that when we talk about some kind of real true random generation, it really is true random, not just pseudo-random. That's what's actually very difficult to provide in an IT environment, or in a microcomputer environment like this. At least I've had the privilege of working with software developers for many years, and I've seen that, yes, we often tended to inherit code snippets from existing sample code from proof of concept solutions, and we had very little feedback on the quality of those.
- And also... - The stack owerflow problem. that people tend to do. There actually are integrated development environments where you can search for it and immediately paste in stack overflow examples, from those which have the most likes there. - Very dangerous, don't do it! But yes, this kind of behaviour unfortunately goes down to the point where that silicone vendors, for example, when they implement such a solution in their own network silicons, they typically provide some kind of SDK, a development kit, some kind of proof of concept program, or script collection, which shows how to exploit, use, parameterize, and thus open up that capability in the given network silicon.
Well, whether it can be done at all. - ...how to kickstart it at all. Exactly, so the point is that while with classical software, you have a relatively large degree of freedom, when you talk about something being implemented in silicone, something being implemented with silicon microcode, like with a microcode running on a certain silicone. There they are very, very careful to make sure that it is optimal, especially in terms of size and runtime and so on. There is already the chance that something could go wrong in the optimization, but let's say that with enough testing, the chance of this can be reduced. How can it be improved? Well, by replacing the hardware, or if we're talking about a microcode that can be re-flashed so there are examples of that, then thank God he manufacturer can issue a new microcode.
In any case, we can interface with this whole thing through the SDK, so that higher level software solutions can use these capabilities. And which is what integrators typically adopt, so that's such a potential source of failure. So, but let's meander back, because I think we've digressed a little bit on this path, So... identity confidence ... and now I think we can put aside gender identity, - which has become so popular lately. - That's right. So the credibility of someone's identity, the ability to verify that, and where certification systems comes in. So how does that work in reality? Everyday life.
I have, I suppose everyone over the age of 18 has a little label or card called an ID card, because now this electronic system has some pretty funny capabilities, but let's put that aside for the moment. But what makes it authentic? It's authentic because it was issued by a third party that we consider to be authentic. If anyone else did that, it would be called forgery. Here in the certificates that we use to identify, say, our digital systems or the services that run on them. Here again, we ideally need to have a third party that is trusted by all the people involved in the communication.
So the other option is obviously when I say, well, I am myself, I'm the third party, you can trust me, mate, there's no problem with that. And then we got into these self-signed certificates... But that's actually, I think, in a smaller, closed environment, where where it's less likely that this issuing party can be compromised, it's more or less acceptable, but of course with appropriate prejudice. So obviously we've already classified these kinds of identifiers into two broad categories, there will be the so-called certificates of public trust... We said we're going to accept that word? Certificates of public trust, which will be produced by some kind of high-level, higher trusted certifier, or a certificate from a certification chain, and there will be the self-signed certificates.
So you can obviously sense from that term that it's a smaller circle, and we have less preference for these, but there are times when we'll settle for... -... yet we shouldn't... -... credibility, yes. Anyway... In between the two, there's perhaps also this interesting grey area, when, we say that something is not exactly of public trust, but the people involved in the communications can all trust it. These could best called private certificates, where there is an entity, say a company, and the company says that it is operating as its own issuer of such a certificate.
And we can even run such a certificate issuer with RouterOS. - We can do it ourselves. - That's right. That's what we want to get to. It's interesting in the standard, by the way, that it actually classifies certificates into two levels. It says that the first certificate that is issued is always called certificate authority, so the certificate issuer. And all further issued certificates will be usable for some service, some client, some sub-organization.
How does the application for such a certificate work? What is the procedure that we typically use today? and then I think we have now concentrated specifically on the 509 certificates that we use today in our own systems, and with which we can kickstart say, an OpenVPN service, an SSTP service, or even a www SSL. First we need to create a key pair. We create a private and a public key pair. We will hide our private key in the vault and use it to sign our various digital certification methods and procedures that we generate. And with the public key we will be able to validate these signatures.
So it's such an interesting thing that the two keys can do similar things but they're not equivalent. And in encryption, we use it the other way around, that we use the public key to encrypt something, but the public key is in itself is unable to decrypt that information. This is why we call these solutions asymmetric encryption. The public key infrastructure, and thus we've moved on to the IETF naming, - looking from the user level, this key pair is then used, to encode the user's own service identity information, into a certificate request packet.
And this packet is then simply taken and signed with its own little certificate. - And then pass that on to... - To the certificate authority. The authority, the certificate issuer.
That's right. And the Certificate Authority will authenticate that certificate with its own certificate. Obviously it will verify the content, say for an HTTPS certificate, - now we could go into the marketing and business value aspect of the technology, that there are class A, B and C certificates.
There's a bit more to it than that which I'm going to simplify it down to. How much do we convince of the credibility of the other side the existence of that organization, its business results, or whatever. Obviously we've gone into this thing here of talking about some kind of truly independent third-party certificates, because as long as we're just talking about running the internal CA of Pityi Palkó and Partners Bt. I'm not sure there's too much deep digging about what OpenVPN certificate XYZ should log in with. But in any other case, what we need to know about these certificates, is that they will contain some attribute that will uniquely identify that entity. So we call that a common name.
And the common name is what you're going to show when you say Leeloo Dallas, and the multipass will indeed say that you are indeed Leeloo Dallas so the underlying certificate is going to say that I, XYZ certify that you are indeed Leeloo Dallas and there's a nice big digital signature underneath that doesn't mean anything by itself, but we have a means to validate that signature. But what else does the border guard look at when Leeloo Dallas shows his multipass? - Her photo? - The expiration date. Oh, right. The expiration date, because these issuing authorities can periodically force the user to renew their certificate, to apply for a new one, to prove again that they haven't changed, they haven't changed their description, they haven't changed their description. Basically, this data has not been compromised in any way.
So we're talking about digital technologies, something that is constantly evolving. Every day there are new things, well, maybe not daily things, but let's say from time to time major innovations appear in this area. There are technologies that are becoming obsolete, -...and in some way or another... - ...The brakes have to be put on. - ...exactly. You can't use this without thinking. You have to put the brakes on, though just before the recording we looked at it together that you can operate certificates without brakes, like Dyatlov did with the nuclear reactor.
Well, it is possible. What were we looking at? We're good with the existing UTC time stamps until 2048, and then we probably ran out of numbers, and then they said we should use generalized time stamps, but if we decide that we want to ensure the validity of the certificate beyond that until the end of the world and two weeks, we should put a special number in there, - which is the last day of a year, - ...9999. 9999. Right. So, in the very distant future, in a galaxy far, far away,
our certificate will still be valid until 23 hours 59 minutes 59 seconds. Which is obviously something we don't want, especially because, - in order to generate our key, we're... -... we're using some pretty lousy procedures. we've used a despicable procedure, which might be calculated by heart by a very clever Korean or an Asian, or the meme is something like, there's always an Asian who's smarter than you.
but let's move beyond that. So it's been pretty interesting so far. Yeah, yeah, yeah. And not too short. So I think there's going to be another episode of that.
Hang in there! See you next time. - Bye! - Bye!
2022-04-05