Black Channel Communications - Securing the Unsecure

Thanks everyone. Uh we're going to get started with the next talk. So um I've got Tim Harrison and Peter McCory for Black Channel Communications and Securing the Unsecure. Okay. Thanks guys. >> Hello. Good afternoon. Did everybody hear me? Okay. >> Yeah. Awesome. Well, good afternoon and welcome everybody. Good to see so many people here. Uh also a bit terrifying. Didn't quite know this conference was this big. So uh that was a good surprise but welcome and thanks very much for coming. Uh so this is our talk on black channel communication securing the unsecure. My name is Tim Harrison and my background is in electronics and hardware development. I've been doing that professionally for about 20 years.

Uh but for most of my life I've been taking things apart. Uh it's only fairly recently that I've actually learned how to put them back together and make them work again. Um I've recently spent four years as the head of engineering for Angoka. That's a Belfast based startup developing hardware security products. Um, and recently, uh, I've moved to Talis and I'm now the head of electronics for Talis Belfast. My name is Peter McCari. I've been a software engineer for about 25 years, believe it or not. Um, so I currently work as a real-time embedded systems uh, architect and I'm desperately trying to remember Valerie's four C's of crisis management. Um, so what we're about to talk to you

about is some of the black channel communications that we're beginning to see more and more as potential solutions to some of the challenges we face. So logistics transport aviation and industrial sectors are all trying to solve complex problems and reduce costs by operating and monitoring devices remotely over open communication networks. However, this presents a unique set of challenges to ensure the safety integrity and the security of that communications channel. So, this talk will explore both the software and the hardware considerations needed when implementing a black channel solution. And we'll hopefully provide you with an appreciation of those challenges and also some potential solutions. Now, to help us explain what black channel communication is, we've selected a use

case that I hope some of you will be familiar with. the Nintendo 64 game Golden Eye. So, for those of you that aren't of a certain vintage or avid gamers, Golden Eye was released on the Nintendo 64 back in 1997. So, it was one of the best games of its generation. Went on to win multiple awards. And if you want a copy of it, I suggest you go and catch Matthew Rainey's history of video game hacking later on. Or following Kieran's talk, you could probably just vibe code it. But how do we make the leap from black channel to uh from James Bond to black channel? >> Well, in Golden Eye, one of the gadgets

that the player can use is a Bond smartwatch, and that can be used to remotely detonate a small explosive charge called a remote mine. Now, in order to trigger the remote mine remotely, there has to be a communications link between the watch and the mine. So, me and Pete had a look at what that communications link might actually look like if we were to implement it in reality. So, we'll look at a few options and then we'll work our way towards what it would look like as a black channel solution to complete that communications link. So, first off, first option really, really simple, a physical link. Just run a cable, a wire, connect the watch and

the mine together. We can use a send a discrete signal to detonate the mind. So, we can just change a voltage level. We don't even need to send a message or a packet. This option is low tech, simple hardware. don't even need Pete for the software for this, which makes it highly resilient because it's always his stuff that breaks and resistant to remote interception and jamming. And because there's no software and very simple hardware, the attack surface is actually very small. There's there's very little to attack. So, job done. Let me stop you there, Tim. So, if we implemented this solution, Bond's going to have to carry around reels and reels of cable with him. If you come across

the cable, somebody could cut it. Also, if you follow the cable back, you'll find Mr. Bond at the end of it. Anyway, health and safety is going to have a nightmare if we start running cables across the floor. Somebody's going to trip over. But our solution will fail. Bond will get caught and the mission's over because of the physical constraints of our solution. It might be secure, but it's physically limiting. Okay. All right. Point taken. Well, how about we get rid of the wire al together and we go for an RF link, a radio frequency link. So, we can pick something in the ISM band. That's industrial, scientific, and medical bands. They're open, so we don't have

much trouble with MO offcom. And we can pick a frequency that has a good long range, something like 433 MHz. So, Bond no longer has to carry any of the cable with them. So, the physical limitation has been removed. And the mine can be triggered anywhere within the range of that RF signal. So, job done. >> Let me stop you there, Tim. So, if we were to use this frequency, our protagonist Boris could attack it using something as simple as a flipper device. Using that, he'd be able to jam our 433 MHz signal and also be able to perform some sort of replay attack. So, again, a solution fails, bun gets caught, and the mission's over. This time, because

the transport mechanism for the signal wasn't secure enough. >> Okay. Okay. Fair point. Well, well, instead of just a raw f link, we could use we could use something like Bluetooth. So, we'd still have wireless control and even early versions of Bluetooth included a level of encryption and authentication. And also, Bluetooth uses frequency hopping spread spectrum. So, we shouldn't have any troubles uh with jamming. Jamming it'll be we be harder to do. So, job job done. Sorry. Sorry, Tim. Give the game away. Um, yes, you could do that, but Bluetooth's open to all sorts of attack vectors such as refle reflection attacks where Boris could potentially impersonate one of the Bluetooth devices replaying the authentication data. And

also in 1997, Bluetooth had a range of about 10 meters. So, our solution fails and Bun gets caught this time because he was either hacked wirelessly or because he was only 10 m away from the mine when it went off. Okay. Well, how about we think about this a bit differently then? Rather than a direct wireless link, what about using something like Laurowan? So, that's low power radio wide area network. It's a low power, low bandwidth and very long range communication protocol. It could cover a large area including maybe a dam or chemical plant ideal for our watch and remote mines. Now, Laurowan does require the installation of gateway modules and nodes around the site, but

we would install those ourselves. We'd own them. So, that should be no problem. So, job job done. Job done. >> Let me stop you there, Tim. So if we were to use something like Lauran, firstly the Laurangan gateway is subject to flooding attacks. It's very easily overwhelmed. Plus we'd have to lay out all the infrastructure ahead of time. So we'd have to send Q branch in about six months ahead of James Bond. I don't know about you. I don't fancy going in before the secret agents. Plus it gives the game away. But also if we did that we'd have to leave hardware lying around the place and Boris could come along and attack the hardware. So changing the configuration

of it, putting his own devices in and potentially performing a man-in-the-middle attack. So yet again, the solution fails. James Bond gets caught and the mission's over. This time because of hardware attacking. Okay. Well, let's well let's keep that theme of infrastructure, but instead of using our own infrastructure, what about using existing infrastructure that exists around the site, such as public Wi-Fi, cellular or saccom? So, that would simplify our solution as there's no need for us to install any hardware. And the existing infrastructure is always present. It's reliable. It includes multiple beers and routes to send the messages across which would increase resilience and prevent jamming. So, job job done. No Tim, sorry let me stop you there. So

if we were to use that we've no way of verifying the safety communications from one end of the endpoint to the other. So critical signals might not get through or if they did get through they might be corrupted. Alternatively the mind could be accidentally triggered by another signal. So yet again [music] our solution fails. Bon gets caught and the mission's over. This time potentially because of an unintentional detonation. However, using existing infrastructure might be a good option, but we need to increase the integrity of it. So, we could look at something like a black channel or a white channel solution to do this. Right, you're really not making this easy for me, Pete. Um, didn't do this in

the rehearsals. This is a really good point, I think, to pause and just explain the concept of white channel communication. So, in white channel solutions, we own all of the infrastructure. So that's all the nodes within the network and also the endpoints and they must conform to safety critical standards in order to send those safety critical signals to detonate our minds. The advantage of this is that we own the network. So we can devise um the security protocols the hardware uh we can define the network itself and we can ensure that only our devices are allowed to join that network. However, doing all that especially across very big networks becomes very expensive. it becomes an

expensive business and we then become resp responsible not only for the data that's sent but how it's processed as it moves across the network. The alternative to white channel is a black channel solution. So let's look at what is black channel communications. So black channel communications is a concept within industrial networking. It's used in safety critical systems particularly within the automation and railway and avionics. The term describes a communication path or medium where the internal properties such as the safety and integrity are known. It's treated as a black box within our solution, hence the name black channel. The first versions of this had dedicated infrastructure between the different endpoints. So everything was understood from the protocols to how the messages

got there. More recently, what we're seeing is black channel beginning to find a new home over things like Ethernet, 5G, and so on. But this has opened it up into public network infrastructure and increased security attack vectors. All of the infrastructure between the different endpoints in this case the watch and the mines could be commercial off-the-shelf stuff. So it's not really certified in any way and we need to increase the importance of security within the solution. So there's a number of different standards that have gone to form the backbone of black channel. Everything from IEC 61508 for functional safety to IEC 61784 for industrial communications. As mentioned previously, these began in the rail industry and they were mainly

used to cut down the cost of certified infrastructures over long distances. Black channel standards are generally more interested in safety than security. So none of them specifically call out any different types of security standards or enforce any security mechanisms within them. primarily due to the original standards that were more interested in safety than they were security. You'll all be pleased to know we're not going to look through any more of these standards in detail, but please feel free to look them up if you get a chance over lunch. So, at this point, it's important to make a bit of a distinction between safety and security. The two can get confused or put together. So safety is

the protection against random incidents which are unwanted and security is the protection against incidents which happen due to a result of deliberate actions. You see as we go through the features that we apply to keep the system safe could also be used partly as the security features of of potential protocols. So there's a bit of an overlap between the two. So you can't be safe if you're not secure. But we would contend that the security should play a critical role in any black channel communication solution. So if we're going to use black channel, what are the safety and security concerns that we need to consider firstly at the software level? Well, the first thing we've got is how

we implement our safety. So normally we'd implement something like a safety communication layer. So as you can see on the left hand side there's a left right hand side sorry in the the white channel communications the safety communication layer travels across all of the different layers from the application layer data layer and physical layer down. So it's able to control all of the timings and bits and pieces and all of the protocols and the message bus and everything else. So it's deeply embedded within the system. On the other side, you can see the black channel solution. In this case, the safety communication layer is not aware of the underlying transport layers. It's only caring about the safety elements

within itself. So, as the black channel communication is unaware of the underlying protocols, it has a couple of challenges. So, the security of the messages that are being sent over the black channel link, the timing of the messages and the security of the hardware at the end points. So if we start with the security of the messages, in order to increase the security at the endpoints, the messages have to be verified and we have to be able to verify the veracity of the messages and the integrity. So as you can see at the top, the black the black channel princ what's it called? I can't read it on this black channel principle. And so inside that

they've got a number of different uh safety mechanisms have been applied and possible measures. So things like sequence numbers, timestamps, those types of things. And they're primarily used for checking that messages aren't accidentally repeated or sent in an in incorrect sequence. But these mechanisms that are implemented also have some valid some valid also have are also can be used for the security of the messages as well. So things like sequence numbers can stop things like replay attacks from happening that kind of thing. So these are all good practice security features but used for safety. On top of that, at the next layer, we'd need to in incorporate the safety protocol inside some sort of encapsulated transport layer. So, if we

can use something like IPSec or VPN tunnel, we can increase the confidentiality of our messages and keep them secure while they travel across the black channel protocol. So to give a rough example of this, this is an example of a a rough rough example of a UDP messages that's containing a safety protocol data packet. So inside the safety safety protocol data packet, you can see the safety protocol measures are implemented in there. At the next level up, whenever it's protected by the transport layer, in this case we've used a VPN. So the authentication header for a VPN is added into the message packet and then the payload for the UDP header and the safety protocol data is encrypted.

This helps to increase the security of the message as it travels across the black channel. If we look at the timing of the messages, so whenever the messages are sent, we face this problem of how do when do we expect the messages to happen. So we want to run this like a bus and we only want to send one message at a time from one end to the other. We want to know when to expect the messages and when they should appear. So to do this we have to define transmit windows and receive windows. Now these transmit and receive windows in this case are both defined and you can see the messages being sent from the

transmit side to the receive side and they're appearing in the correct windows. Then the message is being sent back the other way. But because we don't know the transport mechanism from one endpoint to the other, we can't be sure of what latencies and bits and pieces happen between the two endpoints. So if our timing windows are incorrect, what happens is we end up sending messages outside of these windows. So in order to fix this, we need to go away from using static windows to using more like a sliding scale window. In order to do this, we have to understand the latencies that's happening over the black channel. But we need to do this in a dynamic fashion. So using something

akin to like a ping message bouncing backwards and forwards, we can determine the latency between the two end points and then adjust the windows accordingly. In order to do that and have our windows, we need both sides to agree on a common time base. So we could use something like PTP or NTP. If we did that, there's a couple of problems with this. The first is that NTP offers a good security, a good opportunity for Boris to attack the security of our system. The other thing that might happen is if we're operating in a closed loop situation, we may not be able to access an NTP server. So, it's not really a good solution. And if we look

to do something like TSN, TSN might be a good solution, but we need to implement TSN across the whole network. So because we don't know what's happening inside the black box of the black channel, we don't know what will happen. We don't know if every device within it is TSN enabled. So the timing isn't easy and straightforward, but it is possible. And as we look at the security of the endpoints, it's worth mentioning that some of these systems should have redundancy built into them. So the redundancy is part of the safety features of the system, but can also act as a security mechanism. So in this case we've got two dual security layers in software

that are acting and agreeing and agreeing what's happening between them and then through one protocol stack sending the message out across one bus. This one we've got two independent hardware elements in it. So we've got two security communication layers talking to each other, sending information over two different security stacks and sending two messages across two buses. So to hack such a solution becomes harder as Boris must be able to compromise both of the independent endpoints at the same time. It's not impossible as we're about to see when Tim looks at the hardware security. Tim, thanks. So Pete's looked at black channel from a protocol and software perspective. Um, and from a hardware perspective, black channel only really affects the end

points because Pete said we don't know what's in that black box in the middle. So in this case, it only really affects the watch in the mine. Um, so it's a bit risky, but I'm going to do a quick straw poll and just ask for hands. How many people in the room are either hardware developer engineer or hardware background, electronics background? Okay, cool. Cool. I thought it would be very much on my own, but that's good. Great, good to see. Um, so for you guys, hopefully this will be uh really beneficial and something you've seen before and for everybody else hopefully it's give you a bit of a flavor of the kind of considerations that we have to

have as hardware engineers. So from a hardware perspective, as I said, the it's really just the end points that we care about the watch and the mind and the threat landscape for these kind of devices can be quite interesting. So I'm sure everybody in this room will be very aware um of IT, IoT and OT type systems. So, for example, IoT devices are widely available, numerous, they can access the internet, and they're omniresent. So, anybody can pop down to Tesco's or go on Amazon, buy a whole host of IoT devices, and try and attack them. And they're typically part of large systems where a single exploit can have an impact on thousands of devices. The devices we're

talking about here are very, very different, very different attack surface. They're low volume. They're typically offline, and they tend to be owned or tightly controlled by nation states. and that rules out a lot of threats from the IT or OT world. So thinking about Bond and our watches, on the face of it, we don't really have many security issues from a hardware perspective. However, the big difference here is that those nation states can also be the threat actors. They're the main threat actors we have to think about and they typically have huge resources in terms of people, financing, and equipment. Therefore, we need to consider that any and all vulnerabilities can and will be exploited.

So, assuming the worst can and will happen, it's a catastrophe. Bond is captured. He's never going to make another movie again. Is watch. And some of the mines that don't go off are sent for forensic examination. And a lot of information can be retrieved and used to compromise future operations. Things like mission objectives, information on technology, and the code from the devices themselves. But how would Boris actually go about retrieving this information from the contents of memory from the devices? Well, from an intact operational watch uh or mine, Boris could use a host of devices to attempt to perform a hardware side channel attack. For example, he could use a chip whisperer device shown here to perform a glitching attack on

the processor. Now, in a glitch attack, we attempt to get the processor into an unknown reset or fault state whenever it's executing code. This can be achieved by adjusting the supply voltage to the chip to push it out of operational limits or actually by cooling down the chip again just to push it outside of operational limits. We can even vary the frequency that's that's used as the internal clock for the chip itself. These states can reveal code keys or expose other vulnerabilities that can be exploited. Boris could also attempt a differential power analysis attack. So when a processor implements a dedicated hardware crypto function, it exhibits a very repeatable current draw signature every time that function is executed,

every time it's used. This can be analyzed over thousands of executions of that function and eventually the key used within the function can actually be extracted from the device itself. These techniques can even be used to extract data from destroyed devices. So silicon IC's are surprisingly resilient and even if the outer packaging is damaged, Boris can still recover data from the remains of the detonated mine. There have been cases of electronics that have been recovered from the seabed from a period of about 12 months following the detonation of an explosive device and using off-the-shelf equipment costing less than $2,000, 80% of program memory and flash contents were able to be recovered. So even a device that's

gone undergone an explosive detonation, your your code is still not safe. It's still not secure. So given the level of challenges that we have, what what what can we actually do? Well, my goal or whoever put their hands up, our goal um as hardware designers is to frustrate and confuse Boris to delay the extraction of important data as long as possible with the hope being that Q branch can redevelop the next generation of hardware and minimize any impact. With that in mind, Q branch needs to consider a number of hardware security mechanisms for their watches and minds, including data security, which in this case ensures that the contents of memory are not accessible to unauthorized

persons. Now, to achieve this, it's fundamental and very simple to encrypt all data at rest, ideally using AES 256 to provide a level of quantum resilience. Additionally, important data that doesn't need to be stored long term should be kept in RAM. So when if the watch is destroyed or parted off that information will will disappear and remain secure. And Bon should also have a secure erase button or a zero eyes button on the watch in the event that he is captured. If he's captured he can press this button and a secure erase will be performed on all memory locations by performing multiple readrs to every location. We also need to consider code security that protects the code on the device

which might include things like IP, sensitive algorithms, encryption keys and frequencies, transmission frequencies to prevent access. Code that's stored in program memory should actually be stored encrypted and the processor should implement a decryption on the fly function to enable secure code execution. If the code is never going to be updated, then we should blow programming fuses to ensure that nobody can modify code or change it. And if we do need to update our code in the field at a later date, if we want that flexibility, a secure bootloadader should be implemented to ensure that only verifiable um verifiable known code is executed on the device. Q branch should also select a processor that is able to detect uh detect

attempts to compromise it either physically or through a side channel attack. This can be achieved by certain processors by monitoring for voltage glitches on the supply pins and also monitoring for temperature. We can also add conductive layers around the processor to detect physical intrusion. And if a tamper event is detected, we can delete code or delete keys and to protect the data that's on the watch. As I've mentioned before, encryption needs to be employed. Now the processor that's selected should have hardware enabled uh crypto algorithms and authentication functions. one to ensure faster execution but also to make sure that those functions can't be modified in any way. It's also very sensible to include a unique ID or

reference number for the device and store that in readonly memory or onetime programmable memory and allowing it to be used for authentication of the device and ideally if possible don't have a separate secure element and processor include all the functions within the main processor. There are actually relatively few microcontrollers that provide this level of hardware protection on device. If you're looking for one, a good place to start is the financial services industry such as card payment machines etc. Although there have been some good developments in the automotive industry recently and there's some good examples out there now too. The example I've shown here is a Maxim 32520 microcontroller from analog devices. It's based on an ARM Cortex M4 core and

is one of the most secure microcontrollers around. Unfortunately, this particular device is actually no longer available, which is one of the main reasons I'm allowed to talk about it. So, we've looked at what the processor can reveal, but what about the device itself? So, again, 007 is captured and his watch and some minds that haven't gone off are sent for forensic examination. So, what can the device itself tell Boris? Well, the electronic components that we use can highlight manufacturer data and tell us what manufacturers are used within the supply chain. Fingerprints can be taken off PCBs to identify individuals within the supply chain. Manufacturing markings on the PCBs, that's the printed circuit boards, can actually be used to tell us

when and where the PCB was made and assembled. And as we've seen, the memory contents can expose passwords and code um and names and company names. So to prevent these kind of attacks in this extraction, uh we should use hardware tamper mechanisms on both the watch and the mine. Now, the UK's Defense Science and Technology Labs, DSTL, actually has an employee club that meets weekly where they attempt to defend defeat various hardware tamper mechanisms. And there isn't one they've managed not to defeat yet. So, tampers will never prevent access, but they add another layer of protection to help us confuse, frustrate, and delay Boris. The best approach in using tampers is to use multiple tampers of different types and

use them in layers uh to create that level of protection. Mechanical tampers such as switches, electrical such as meshes or wire guards or traces and optical um such as ambient light sensors. Also to further frustrate and confuse, it's really obvious to Boris when a tamper goes off the code gets deleted, the keys get deleted or the watch becomes inoperable. So rather than doing that, make the watch work intermittently. change the keys, change critical parameters in the code. It's not obvious that it's being tampered. Um, Baris thinks he succeeded in getting the information he needed, but it's actually just rubbish. It just confuses and delays him even further. Armed with this information, Baris could attempt to target component

manufacturers in a supply chain attack. If you follow the news closely, you may have noticed a large number of recent arson attacks on manufacturing companies and warehouses within the EU. If Boris removes the ability for us to ship and make specialized components, we can no longer make our watches and mines anymore. Alternatively, Boris could target the printed circuit board manufacturer or the PCBA manufacturer. Now, he wouldn't do this directly, but using the information extracted from the watch, he would target an individual working for one of these companies and and based on that, he could coersse, influence, or even blackmail them. Now Boris could instruct the employee to simply damage the watches and the minds coming off the

production line, but this kind of damage would be easily picked up by final testing and QA testing at the manufacturing site. So rather than that, in this example, Boris will simply ask the employee to change one component. And in this example, it's the crystal oscillator. So that's used to generate the internal clock frequency for our processor. The crystal oscillators that Boris has supplied uh frequency tolerance is starting to drift. It's starting to drift out of tolerance. So they're likely to pass the manufacturing test at the manufacturing site, but months later whenever Bond actually comes to use his watch and mines, the frequency will have drifted so far out of tolerance that communications link won't work anymore.

Another approach that Boris could deploy is to replace the processor itself with a counterfeit one with malicious code already installed onto it, potentially uh in the bootloadader itself. This code could be used to disable the mine detonation function if the watch detects that it's within a certain GPS location. Similar real life examples of these kind of supply chain attacks have happened and have been reported by a number of news agencies. To prevent these types of attacks, the hardware supply chain must be secure. And to achieve this Q branch should follow NIST guidelines on securing the supply chain and importantly as much processes as possible should be brought inhouse. So the design procurement manufacturing test and ideally secure

programming of devices should all be done within Q branch. Finally to ensure that no data can be extracted by a forensic examination sterilizing and cleaning all PCBs to remove fingerprints and hairs etc. And also building on this, removing all component markings using laser ablasion and making sure that the manufacturer places no markings um or instructions or details on the PCBs themselves. So some takeaways from today. Golden Eye is a fantastic game. If you have never played it and you want to grab a copy, Matthew Ry's talk will show you how to get that for free. Um, we've also learned 10 meters is far too close to stand stand next to uh to an exploding mine. If we were building bones watch

today, black channel could offer a viable option for the communications link between the watch and the mine. But our communication safety protocol layer needs to be protected by another layer of security. The hardware itself needs to be secure as well. So we need to apply that and we need to encrypt everything. So especially our keys, but trying to keep them secure can be challenging. And finally, the supply chain probably offers Boris the best chance to attack our solution. >> So that's it. Thanks very much everyone. Thanks for listening. >> Thank you. [applause]

Any questions?

So if it's encrypted using a hardware crypto block. It'll be encrypted. The output will be the same as if it was encrypted using a software implementation. It'll just go through a hardware block. When it uses that zeroization button, it will zeroize the encrypted data within memory. So, it won't touch the hardware block itself. That particular device that I showed that Maxim device um it did have a mission, it actually has a mission impossible style mode that you can activate based on a tamper where the device will complete render itself completely inoperable and it will no longer work. it'll do that uh that Mission Impossible style thing. Um but but normally just secure erasing the memory contents is enough.

Okay. So the question was in terms of those security mechanisms and tampers uh is that software hardware job or is that another team? Um so from a hardware side uh we would do that ourselves as part of a uh design for security review um and then compare what we've done against a set of guidelines that have been derived from the kind of standards from from NIST and other organizations. From a software side >> yeah from software we'd be reading those tampers as well. So we'd need to react whenever the tampers go off. So sometimes they can be activated purely through hardware. Other times you want them to happen whenever the device is powered on or if it's been activated

when the device is off. Next time the device is turned on, the system has to react and do something else.

>> Why standard not standard? Tim any standards good. No, no standard bad, any standard better. I I selected a N standard because there's a lot of N standards regarding hardware security mod modules and tamper mechanisms with within that. So I for this I selected the N standard because they've got good standards on hardware security for specifically for hardware security modules.

is me is it? Yeah. Uh there's a number of people do things like safe arts and uh safe exchange. I think Whitenstein is one of the big providers of those types of solutions. So more and more people are beginning to look at the how they can implement things like black channel because it's so cost effective as well if you can get it to work correctly. But there are a number of growing manufacturers of those types of devices, both software and hardware devices as well.

>> Okay, super. What an incredible duo. Thank you both so much. Round of applause. Great job. [applause] Thank you. And uh lunch is hopefully served at the moment upstairs um behind where the sponsors are. So enjoy. We'll see you after.