 It's really, yeah, I mean, I have a lot of different solutions to these things, and we've got a lot of new ideas, and I think that's actually one of the main things that we stay up to. I think that's the best to do. Good morning, everyone. I'd like to welcome all the party survivors from yesterday, I'm sure that, and those who pretends as you are in the party, that's also fine. My name is Alex, I'm here at the session today in this program, a short announcement, if you're going to enter the room or go out, please be careful with the door so that we keep it quiet. Also, I'd ask you to turn the mobile to the silent remote so that we do not disturb as they can. And the last thing today is also the full day, so at 4.30 we will have a competition with prizes, so I do encourage you to come over and to participate in that competition to get the prizes that will be available. That's all about the organization announcement, and now please welcome our speaker, Sabrina. I'm going to talk about Maxec, which is a standout for encryption on wired networks, wired LANs. So, brief outline, first I'm going to give you an introduction to what Maxec is and why you've probably never heard of it. I'm going to briefly describe the implementation I did for the Linux kernel and show you why you would want to use it and how to use it, and that'll be about what remains to be done. So, first, what is Maxec? It's an IEEE standard for encryption of our Ethernet LANs, and you can use it to encrypt and authenticate all your traffic in the LAN using Galois control mode with 128 bitkits. So, why would you want to use Maxec? Well, our security in LANs at Layer 2 is not really good. You could have some rogue DHCPs, some rogue router advertisements, and it's pretty easy to do some ARP and Ndisk spoofing. So, you might want to secure your LAN. IPsec is only at Layer 3, so you cannot protect your ARP and Ndisk traffic if you have untrusted links. You could also use Maxec in a cloud environment if you use VxLan or Geneve. There's more to do, some encrypted VxLan stuff, but encryption for VxLan will be only on the dinner endpoints and not in the VM, so the tenant in the cloud would not have control of other keys. So, why would you want to do that? On the other hand, with Maxec over VxLan, the tenant has control of the keys, the encryption is done in the VM, and that seems much more reasonable. Some Maxec concepts and architecture. So, in Maxec we have the secure channel, which is a unidirectional channel from one of your nodes to any number of other nodes. And a secure channel is supported by a sequence of overlapping secure associations. So, the associations within a secure channel, for every frame that is transmitted over Maxec, you will have to use a key, and the keys are linked to the secure associations. And you have also a packet number that is used, for example, for replay protection. Next, there's another important concept you will need is the security entity, which is the instant of the Maxec implementation. You could run multiple Maxec instances on the same node, even on the same network interface. And the uncontrolled port in IEEE terminology is the normal network interface that provides insecure service. And that's what you build Maxec on top of. So, if you want to configure Maxec on your machine, once you have the implementation, you have two options. The first option is configure your keys yourself. So, you set up your secure channels and your keys manually. And that's the example use cases I will show you later. The other option is to use an extension to 82.1x. So, 82.1x will do the authentication between the nodes for you. And then you use the Maxec key agreement protocol. And that will allow discovery of other Maxec nodes within your network. And set up all the secure channels, secure associations, and exchange of keys. And this will also allow synchronization of packet numbers so that you can do replay protection with up-to-date packet numbers. So, Maxec can work with two different modes. You will always have integrity and authenticity of your traffic. And you can also encrypt it if you want. So, the default crypto-algorithm that you use for Maxec is yellow account mode AES. And that will provide you authenticated encryption with additional data. So, your entire Maxec payload from the beginning of the Ethernet header to the end of your payload is always authenticated. And then your network administrator. As a network administrator, you can choose whether you encrypt the payload, say IP header and TCP and whatever you have over that. Or you don't encrypt it. And then that will determine if you use how the parameters for GCMR set up. Other modes that you can use with Maxec is validation modes for incoming packets. So, the most secure mode will be strict validation. Anything that's not completely protected and properly validated and cryptographically validated is dropped. That's not secure traffic. You just don't want it. You can have also check validation, which if you cannot validate a frame, you accept it. But you mark it as you count it differently in your network statistics. And you can disable validation and receive, then you accept everything that comes in. Of course, if you have fully encrypted frames, you cannot accept it if you don't have the keys that matches it. But if you're using authenticated only traffic, then you can accept this without the right key. So, I talked a bit about replay protection. Each Maxec frame has a 32-bit packet number with it. And on receive view, the node may decide to validate the packet number against its receive window. That's optional if you don't want to enable replay protection, then just don't configure it. Let's look at what the protocol looks like. Just to remind you of what an Ethernet frame looks like, destination, source address, and then your Ethertype, and whatever you have over that IP header and everything. So, the protected frame, you add a set tag at the beginning of the frame. Before your payload, the user, the Ethertype that we had before is part of the Maxec payload, and you add a new Maxec Ethertype. And at the end, you have the ICV, the integrity check value, which is the cryptographic signature. And if you encrypt your payload, then everything starting from the original Ethertype of the packet will be encrypted. So, the set tag here, I put the Ethertype here. So, there's the type control information first. I will describe what's in there later. And the association number, since you have a sequence of secure associations, you need to put the association number here so that the receiving node can choose which key to use on the receiver to decrypt the packet. The association number is two bits, so you can have at most, you have a sequence between you loop over your four association numbers, when you get to the end of one association, then you switch to the next one. Then there's the short length field, which indicates that the frame was under 64 bytes. And you have an optional secure channel identifier. It works a bit like a VLAN type, so you can have multiple secure channels at the same time. So, the secure channel identifier is composed of the MAC address of the house that sent the packet and a 16-bit port number. The contents of the TCI fields, you've got a few really interesting bits here. The SC bits indicates that the SCI, which is optional, was actually in there. And then you've got the encrypted payload bit that the payload was encrypted or not, and the change text bit, which also helps you detect that, for example, since the ICV length is not defined by the standard, if you don't use the default ICV length, you would set this change text bit. Now, how MACSEC interacts with VLAN. If you want to have your VLAN header protected by MACSEC, then that's what you would do. You would have your Ethernet header, VLAN header, and then your data. And you would put all the VLAN header plus data inside MACSEC, inside the MACSEC payload, and that would end up being encrypted. Now, how packets are handled, and when you transmit a packet, you've got your Ethernet header and data coming from the network stack on your machine, and you would push a sec tag at the beginning, like to do with a VLAN. Then you compute and append the ICV for the packet, and you pass it down to the underlying device, say your normal network. On receive, it's a bit more complicated because you have to verify the packet, so you get the same packet that you transmitted before. You first verify that the packet and sec tag formats are correct, that you didn't have some completely wrong things in there. Then if you enabled replay protection, you would say that the packet number is correct. Otherwise, you just drop the packet so you don't give any feedback to a potential attacker. And that would help defend against those stacks because you don't want to spend a lot of time doing cryptographic validation on the packet that is obviously not correct or that end up being delayed somewhere or something. Then you decrypt and verify the ICV, and then you recheck the packet number once the sec tag has been validated as being sent by a trusted node. Then you remove the ICV and the sec tag, and you can have a normal packet that you can send out to your network stack. Now, I'm going to give you a few details of the little external implementation. So, the way a MagSight device would... MagSight would look like once you configure it on your machine is that that creates a new network device like your network card or like you would have if you set up a VLAN on your machine. And the master device, which is the device under which your MagSight node, the device that has access to the real LAN that you have, will see only the raw packets, which is all your protected traffic. And the MagSight slave device will see only the normal friends. And you may also have some non-protected traffic on your LAN. For example, A2.1X will go on the unprotected interface before you have actually set up the device. And this model is actually a very good match for the uncontrolled and controlled port model that the IEEE standard uses. And for those who are interested in the Linux model, it uses RxHandler and the NetDevice operations like my VLANs. On the crypto side, we just use the normal crypto API from the kernel that provides it. We already had all the authenticated encryption implementation available. And it can also use hardware acceleration if your CPU has it, which I think most recent Intel CPUs at least have. On the configuration side, we use both RTNetLink and GNetLink. RTNetLink is what you use to create your usual NetDevices and GNetLink provides the configuration of all the very maxx-specific things like the secure associations. And GNetLink is really nice for that because it provides good demultiplexing capabilities. So it makes for a quite clean API. So I'm going to give you some use cases and configuration examples. The configuration examples rely on IP routes, which is the way to configure networking stuff nowadays. And if you're not very comfortable with IP routes, Phil is going to talk about it soon and you should go see his talk. So suppose you have your LAN in black. You will have the physical links. So you have a few hosts and a switch. You have two ways basically to configure Maxx. The first way would be to configure Maxx on the hosts and on each of your switch ports. But for that you will need a switch that has Maxx support. If your switch doesn't have Maxx support, you can still use Maxx between the hosts directly. And the switch would see only the Maxx protected traffic. So if you don't trust your switch, that's also the way to go. So here are a few commands that tell you how to do basic Maxx configuration. You create IP link add link on your normal network interface, ETH0, and you create the Maxx zero device with the type Maxx. Then you create a transmit secure association with a key and initial packet number. The packet number will grow after that. You need also to create a receive secure channel for your peer. And you use the Maxx address of your peer machine and the port number by default which is one. And on that secure channel you need to create the receive secure association with the key that matches the... So you have key one on the transmit for the second host and key one on receive for the second host. Some important configuration parameters that you would... When you get close to exhaustion of your packet number for one secure association, you need to set up another one because you don't want to reuse the same packet number with the same key. So you set up a new secure association with a fresh key and you switch secure associations. So with that you would enable the next secure association. You can enable encryption by default in the kernel implementation the encryption is not enabled, but if you create your link and then you can later set it up to encrypt you can just do that, switch it on and off at any time. That's not a problem. You can also put this encrypt on bit right here when you create the device. That's IP routes syntax. And to enable replay protection that would be with replay on and the size of the receive window that you want depending on your land or you may want a different replay window. So that was a basic setup with one secure channel. If you want to have multiple secure channels for example because you don't want host one and host two to be able to see each other's traffic with host four so you want separate keys for the communication between host one and four and for host one and two. Then you would set up a secure channel that's between host one and four and a different secure channel between host two and four. So nodes one and two have only one secure channel it's the same configuration as before but host four has two secure channels and you can use completely different cryptographic parameters you can use encryption with one and only authenticity for the second one for example that's completely separate. So that's mostly the same configuration as before. You create your maxing device, you create your transmit secure association and you receive your secure channel to communicate with host one and for host two you create with the MAC address host two. The only difference between these two is the port number because you cannot have two transmit channels with the same port number and on host two then when you create the receive secure channel on host two you would have to use that port number here instead of one you use port number two. So I talked a bit about using VLANs of a Macsec earlier suppose you have one, you have your physical link between host one and host two there may be a switch in there, it doesn't matter. You can create a secure channel, you can create one Macsec device and a second Macsec device and have your VLANs over the Macsec devices so you would create your VLAN devices on top of the Macsec devices instead of creating it directly on top of HGH0. So that's what it looks like. You first create your Macsec device over HGH0 you configure it like you did before and then you create your VLAN device over Macsec and if you have a second one then you create a new VLAN oh no that's sorry, that's the two pairs for VLAN one and then you create your second VLAN so now you create a new secure channel on your host with the new port number and then on top of that Macsec device you create your VLAN you can also use Macsec with bonding bonding devices so link aggregation so suppose you have your two hosts host one and host two with each a bonding device and you have three physical links between the two Macsec would not be configured over the entire bond but over each individual link and then you put each individual Macsec device in your bond so that's your enslaved Macsec devices not the real links which means that your LACP control traffic is going to be protected by Macsec so you create a configuration you create your bond that's up to you then you set up Macsec on each of your bonding link so that's same kind of configuration as before and then you enslave all your Macsec devices in your bond I put only two here but you choose now for Macsec with VLAN setup suppose you have an underlying network for your cloud and you have your virtual switches that are so that part is controlled by your cloud provider and in your cloud you have two tenants A and B which have some virtual machines on each side of the cloud and they have their each of the tenants have their own VXLAN tunnel so tenant A has the blue tunnel and tenant B has the yellow or orange tunnel and tenant A decides that they want to have a Macsec they want to use Macsec over there because they don't really trust their cloud provider they want to encrypt their traffic so they would configure Macsec over VXLAN and that's what a packet going through the underlying network would look like you would have Ethernet header then IP header, UDP and VXLAN and then the same thing I showed earlier with the Ethernet header and sec tag all this part is created in the virtual machine of the tenant and all that is added by the virtual switch from the cloud provider which means that all the cryptography is done all the security is done by the tenant himself and they don't have to rely they don't have to trust their cloud provider so if you want to set up an example like that that would be normal VXLAN tunnel creation using IP route but if you are just a cloud customer you don't set up your VXLAN tunnel yourself and then you would just create your Macsec link over the VXLAN tunnel that is provided to you and that was completely transparent you don't even have to it doesn't matter it's VXLAN tunnel it would just go well so in conclusion I'm going to tell you a bit about what remains to be done for Macsec in the kernel for all the implementation doesn't have some optional features of Macsec one of these features is a confidentiality of set you could decide that the first 30 bytes of your packet are not encrypted they are only integrity protected so that means that your IP header would be visible to the switches in the middle and there's also an additional Cypher suite that has been standardized which uses 256 bit keys I know that at least some Intel, IHDB so 10-gig nicks have support for hardware of loading but that's not yet implemented but that would allow to... these nicks can do Macsec at the full 10-gig line rate which is not something we can do with the current Linux kernel implementation so we're looking to implement this hardware of loading and also to have some performance improvements so that you can use Macsec better in user space for now I have only IP root support but network manager support would also be interesting and the WPA supplicant already has mk so Macsec key exchange support but it's not yet... you cannot yet use it to configure the Linux kernel implementation that's something we'll do soon and if you have any questions I don't remember exactly the last measurements but last year I was running also with debugging features enabled so that also kills a bit your performance where I was not at one gig yet but I don't think I was using a lot... the crypto extensions from the CPU so if you say in percentage how much Macsec will take from the bandwidth or if it's not possible to say 30%, 40% well it depends... I think it depends more on your... if you have 10 gigs then we're very far from that for now if you have a one gig link we're probably not too far I noticed in some advertising materials like Qlogic that they also support Macsec who I didn't know idea to enable it or to program it I only talked about Intel because Intel has published their specifications and we can implement it other companies I don't have any specification though so we would have to rely on them doing that if the Intel implementation is compatible to say with TSO can you pass a huge frame into it? not sure the key exchange is an extension to 802.1x it's this MKA Macsec key agreement protocol so you do authentication with 802.1x and then Macsec, the MKA clients can exchange keys between themselves forgot to is there already any adoption or acceptance from other vendors like Cisco, like... I think Cisco is an implementation Juniper has an implementation Brocade I think also has implementation in some of their switches so there are some... you can get it in other places but you get the VLAN once you decapsulate at the other end so you can also put the VLAN on the other side of the site type but if you want to encrypt your VLAN traffic your VLAN type you can it works both ways you can do it both ways so you can have a VLAN either after the site type or before the switch is connected to the Macsec connection so the switch is able to decrypt the packet and read the VLAN IP and encrypt it again some switches do that oh, we tested with Juniper oh, sorry yes? we addressed it in the 3rd type I used to know that it is set with IPv4 or space Macsec so the information IPv4 or space then moved to the site type it's moved to after the site type that's your IP as a type it's here yes? I have two important things which you usually do after the VLAN the question is we usually do one opening and then doing VLANs over the platform how it fits to this because I see that you have to do Macsec over each interface yes then you configure your VLANs over your bond yeah it's just a network device but in that case I need to have because this is between the bonds and between the bonds but usually I have a normal switch connection so in that case, if I would like to have a protected bond I must have probably the switch with the Macsec side yeah if you have one if you have a switch in one side to be one of your bonds then, yeah, it would need Macsec support can you make Macsec over the bond device or if Macsec over the device I suppose it's possible to make Macsec work over your bond but I haven't looked at that that's the setup I... if you do it this way you have protected also the... yes yes if I don't look at the Macsec many companies I suppose you could do that I haven't looked at it I don't see a reason that wouldn't work but I cannot promise you anything about that I haven't done measurements on that but yeah, probably it's going to come in works with variable MTU and if large MTU is also supported if it's okay I don't see any reason that wouldn't work yes does Macsec have any application in wireless security so for example here you have a wireless network that doesn't have any encryption does Macsec... does everything take you that way? Macsec basically needs only an Ethernet header an Ethertype so maybe I would like to know do you think that I want to I don't know can you repeat this question and also answer? he wanted to know if you can use Macsec with an unsecured Wi-Fi network so Macsec really needs mostly a full Ethernet header with an Ethertype so possibly it could work I can no I can really test that right now but sorry you will do most to most not the most should should should possibly yes because you if you have an unsecured network that you you didn't configure it yourself you just use what's here if you have a network that you didn't configure yourself you just in a hotel or something then maybe you want to secure traffic with your friend in another room then that would be a reason for yes your opinion does it make sense to use Macsec on the form network operation like the FCB and IPsec relations and if we want transmit on the IPsec does it make sense to use IPsec for other network operations you could even use IPsec of a Macsec if you want much best talk so far on the DEF CON your talk was probably the best talk I saw so far on the DEF CON