[Auto-generated transcript. Edits may have been applied for clarity.] I. To say.
All right along with you. Good afternoon.
So let me start by a quick introduction. Um, I'm even Martino, which I'm acting head of department.
This academic here in in computer science department.
And it is my great pleasure to introduce to you, professor surgeon champion, um, visiting us.
Um, from Keith Turek, a fellow Croatian, um, surgeon is a full professor at MPH.
He's also chair of Zurich, uh, Information Security Institute.
Uh, um, for security.
Privacy associate by, uh, associate VP for, uh, digital transformation and government at and uh, among all these roles, you also do some research.
So you just, I believe, finished your ERC consolidator grant on secure position in various networks.
So, um, his work is, uh, the boundary between the physical and digital domain,
starting with analysis of, uh, physical properties, meaning signal propagation,
wireless communication, and actually using physical laws to create security properties such as,
for example, something we're going to hear about, um, called distance ball.
And, uh, working all the way up through smartphone sensors to the satellites and digital infrastructures.
Maybe just to give you a quick example, around 2010, you know each other for some time.
So around 2010, he published the first paper on the vulnerabilities of so-called PCA system of a PKC suppressive keyless entry system.
Now, this key but many high end cars back then. Now it's more of a commodity.
But back then it was um, it was quite famous and expensive to have a key that would allow you higher level of usability.
Basically, you would just need to be near to open the car and enter the vehicle and, and such.
And most of the first one to have a systematic evaluation of such a system, showing, of course,
that there is a logical breakage in design because, uh, ability to communicate does not imply physical proximity.
And so he was the first one to introduce relay attacks on that system.
At the same time. When are you asking what the industry has done about it?
Because as a security researcher, you are you are required to do this, uh, something called the responsible disclosure.
So he and his team went to all the car manufacturers, and actually the car industry did nothing.
Right. They said, well, the usability is a great important sales factor.
And, you know, um, these events won't happen today.
You can go to YouTube or, you know, there are millions of videos how expensive cars,
especially Teslas and similar ones, are basically being taken away in the middle of the night.
Interestingly, my neighbour also got his brand new BMW that way.
It was picked up by my Rinke, uh, smart, uh, right, uh, doorbell.
But it turned off notifications. So yeah. So so yeah, it was late.
Anyway, um, because the industry did nothing certain, uh, created a secure distance measurement system there.
Then in the spinoff company that eventually, later on was a client and then successfully.
And today in most of the car keys, you have surgeons secure distance measurement protocol.
Okay. So, um, with this, I will stop.
And, uh, before I finish a bit of housekeeping, first of all, uh, the strategy lecture series,
our distinguished series is generously funded by Oxfam, Oxford Asset Management and, uh, yeah, thankful for that.
And also, please stay after the lecture for some tea, coffee and biscuits just around the corner here.
And with this, uh, let's welcome together Professor Chapman.
So thank you, Yvonne, and thank you all for, uh, for coming.
I'm I'm going to try to cover two topics. One is more kind of mundane and related to, uh, smartphones.
And the other one is, is related to, uh, maybe our, our future and cyber physical systems that will be deployed and the and the system and
what I believe are the systems that we need to build in order to secure our future.
Because otherwise, I, I think it's going to be very scary.
So let me, uh, start with, uh, with one simple question.
And that's do you truly own your your phone and.
And here the question is, is somehow similar to the one that you or the to the test that you can you can do when you ask yourself the if you own,
if you truly own a house that you live in. And a good test is to try to nail a picture on the wall.
Right. So the similar thing you can do with a phone, you can ask yourself, what can I actually do with this phone?
So how much access do I have, uh, to to what I want to do on this phone.
So whether there is some hardware that you want to modify or that you want to configure in some way, uh, you sit over there.
So you being the apps potentially that you can develop and install,
whereas there is this whole ecosystem below not only of operating systems but potentially hypervisors.
There's a lot of firmware that's being deployed on these phones.
So there is a lot of control that is being exercised for good or bad by different entities in the in this ecosystem.
And these could be either big tech entities like Google, Samsung, Apple, uh,
Qualcomm and, and so forth, or even a lot of, uh, third party, uh, entities.
And what you can see here already, if you're unfamiliar with, uh, with the phones, is that the phones are divided into or at least this arm, uh,
platform is divided into what's called the normal world and the secure world, which is, uh, typically running something like arm transition.
Right. So that's the architecture.
And, um, there you already see a division between secure services and potentially, uh, normal, uh, execution of of, let's say, users users code.
That part is also heavily controlled by by different commercial entities.
And as a user, you typically have no access to these secure services you can't easily configure.
So this is not only about control. So this ecosystem is is quite is quite large.
We have hundreds of mil. I mean it's hard to estimate, but there are 100 over 100 million lines of code that are that your application sits on top of.
So if even if you have something like a secure messenger running on top of your your code,
it's, it sits on this large ecosystem of, of um of code which.
Also then results in vulnerabilities being being disclosed.
Uh, every once in a while, a lot of them are zero day,
meaning that effectively you don't really know about these vulnerabilities before they are publicly released,
but they have been out there in the wild and and potentially have compromised your phone.
And clearly, with these AI tools, tools coming up that can analyse large code bases, we can expect more such vulnerabilities to to appear.
This is not surprising or shocking to any computer scientist.
This is just a link to some of these zero days published by Google.
So they keep on coming. And so you could even even say that at any given point in time, you're probably exposed to some of them on your on your phone,
and they might be weaponized against you, or it depends on what kind of target you tend to be.
And this is I'm not the first one to notice. Reports about security vulnerabilities are everywhere.
Uh, we can see politicians, people being targeted.
Also entire organisations being being targeted. The same applies to control.
Um, in terms of controlling this, this ecosystem and effectively some of these entities acting as potential gatekeepers to,
uh, to the functionality of the phone. There are numerous reports on this.
Uh, the latest one you can maybe see by graphene, for example,
which is a secure operating system that you can run on your on your phone complaining about attestation,
being, uh, being forced into some, um, application ecosystems and effectively breaking some of the functionality on their, on their phones.
So this is this is clearly a problem, right, that we have that we have entities that provide a lot of service.
So they create these rich ecosystems. But in some sense we are dependent on them.
Right. So we are dependent on them to control access to resources.
Because the way that computer systems are designed is that is that someone needs to manage access to shared resources like CPUs,
memory, uh, peripherals and so on.
And we put this big fat operating system in between, plus other layers in order to, to mediate this access and through a a set of privacy, security,
uh, arguments, you can then then try to argue why certain access of an application is to an A from an application is actually restricted.
So this means effectively that in today's uh, architectures, access to peripherals such as screens, networks,
every sensor needs to be mediated by these uh, OEM, uh operating system providers like Apple, Apple, uh, Google, Samsung and so on.
It is not only about control, it's also about availability.
So if those entities decide to, to, um, stop their service, your functionality, whatever that is, would, would equally, equally stop.
And also it's about configurability, which is lack of developer control over what they want to to do with the phone.
I was involved in a broader, um, effort by ePFl and back then during the pandemic, where we were working on contact tracing frameworks.
One of them was, in the end, adopted and deployed by Apple and Google.
And one of our main challenges was just access to Bluetooth and access to Bluetooth beacons.
And this was heavily guarded for, for, uh, some good reasons by, by Apple and Google.
And this led to a lot of frustration, um, among among researchers because many ideas that we had even in that state of,
of, let's say, uh, global panic, we could not implement, um, our ideas.
So clearly you can run alternative ecosystems, right?
You could say, I don't like this ecosystem dominated by my big tech players.
I'm going to switch to two alternatives.
And these might be some Linux phones. It might be graphene.
If I built alternative ecosystems that give you potentially more control over over the phone.
But they also have a restricted functionality because you might not no longer be able to run an app that, um,
of your bank or maybe some favourite app that potentially requires a different type at the station,
or wants to be run only within a Google or Apple ecosystem.
So this is you lose a lot of functionality.
So this means that we essentially are facing sort of a choice.
I do carry two phones with you.
You have a, a secure phone and, and a sort of general phone, uh, on, on which you can install some less critical application or,
or you just suffer with the consequences of, of each of these ecosystems.
So we raised this question some, some years ago. Why does it have to be like this?
And can we actually design something else. So can we have nice nice things in a nutshell.
So a phone that is actually secure, open, developer friendly and can actually be controlled by the user.
But I'm going to refine this, this statement because I, we didn't want full control by the users.
We want actually shared control. So this phone needs to be controlled by your user,
but at the same time functional and compatible with these large ecosystems like Android, iOS and so on.
So we started this in 2020, started thinking about this, and then published the first paper in in 2021.
It was a really difficult publication process, I can tell you, because, uh,
some of the ideas that we wanted to push, they didn't find immediate acceptance in the, in the community,
but effectively we wanted to create a phone that contains several phones, for example,
to where you can run one E.M.S. or more and one or more domains that execute some secure apps.
But those apps should have full access to the hardware peripherals.
They should be able to run bare metal, essentially. So we wanted to move from this ecosystem on the left where we have this monolithic, let's say,
monolithic design to this system on the right where we would create ecosystems that are equally privileged.
So we didn't want to create a phone where the user dominates these large OEM ecosystems, because this might break their their security model.
Right.
So we wanted to build a phone where you can execute your workflow bare metal with full access to peripherals in parallel with the existing commercial,
uh, phones. And what can you do that there?
You could create domains, for example, where you run in parallel with, let's say, Android, another secure operating system,
or even a self-contained bare metal application that runs directly on the on on the course.
So one of these, one of these um, domains needs to be protected from the user.
So whatever the user does on the phone and needs to be controlled by um,
and others potentially need to be controlled by the user or in any combination of those.
So we are talking about really equal privilege.
And we wanted to do it in a way that that also doesn't over privilege any of the layers on the phone.
Now come to the to the how we we did it. But just to set aside a little bit of a of of a scene,
what we wanted to achieve is that we wanted to have secure domains that have direct access to screen and networks.
So when I'm running in a secure domain, I want full screen access without having to trust Android, for example.
So when I'm running in my domain, that peripheral is tied to my to talk to that code and cannot be modified or inspected by Android.
The same with network, for example, or with any other sensor or any other peripheral that we want.
Equally, we want that high, high availability. So meaning that if I if Android suddenly drops.
That this other domain can take over the functionality and and connect to the network and continue running as, as if nothing happened.
So we wanted to remove this dependency on these on these large operating systems while
allowing them to still run on the platform fully isolated from the from the rest,
because the same properties that we want for a secure domain. We also want for for the OEM code.
And at the same time, we didn't want to introduce a huge layer below these,
these systems and a large TCB because that wouldn't that wouldn't make sense to introduce yet another dependency.
We also wanted to do it in a usable fashion, meaning that so how would you now even even interact between these these domains?
Well, this is not a very complicated idea, but but it's it's, uh, it needed to be to be to be done.
So a simple press of a button where when you're running your, your phone, you can just press a button.
This button is, uh, so the, the firmware has been configured such that this button press cannot be interrupted by,
uh, or modified by any of the of the running domains.
You get into a mode where you can switch between different domains.
So either you press a button and you keep on switching between domains or anything of that sort.
So at a press of a button, you switch between, uh, let's say your Android and your secure, uh, domain running, for example,
a signal messenger and wireless and, and then you can enable all kinds of interactions between these domains.
For example, your Android could be receiving a notification that you have a message in a secure domain without presenting a message.
And then you can press a button switch and see the message in a secure domain.
You can allow interactions between these domains, but clearly according to any policy that you would that you would like.
So of course, all this sounds very, very nice when you present this kind of a vision and, um, and then, um, clearly somehow it needs to be built.
Or the question is, can you even build this on today's, um, um, platforms?
And, and what I've learned over these 20 years as a, as a professor is that there is nothing that dedicated students cannot do.
Um, so it took us only for only more than 40 years going through these different, uh, prototypes.
So first, for some arm board that we that we worked on, there was a, uh, an emulator that we used.
And then you see the first examples of, of phones.
These were some older phone models that we, that we built.
Uh, I mean, we didn't build a phones, but a firmware that we updated.
And this was in summer 2024 when, when some hope that this can actually run on,
on phones without without much, um, uh, let's say, uh, much disturbance to the ecosystem.
And then finally in, in March this year, uh, a spinoff company from our,
from our department presenting this prototype at the Mobile World Congress in Barcelona,
where we, we showcased essentially that such a system can be, can be built.
And so how does it work? Well, here's the latest prototype, which is from now from well, effectively from a week ago or so.
So a prototype of a phone where you switch between Android to a Linux, uh, operating system running some web apps.
Three Ma here that you see is, uh, is a sweet, secure messaging app.
So we reported it there. So every time that you switch, you switch potentially to a locked, let's say lock screen.
Um, now you switch back to Android and you can do that as many times as you, as you like.
And you can run several of these of these domains. So that's that essentially tells you what we built.
What can you do. But then the question remains is how?
How did you actually build this. Right. I mean, what do you do?
Well, all problems in computer science clearly can be can be solved by another level of indirection.
This is clearly not me who said this? Apparently. Roger Needham, uh, and a few other people also also, uh, said this.
So the first idea would be to to Virtualise you put a hypervisor underneath all these different domains,
these operating systems, this hypervisor is going to virtualise access to peripherals.
And there you go. This is exactly the path that we didn't want to take.
The reason is that you will replace this control.
That you wanted to, um, to give up.
You didn't want to have within these operating systems with now a hypervisor which will again manage access to these, to these peripherals.
So we did not want to virtualise, uh, peripherals.
We didn't want to virtualise access to, uh, to hardware.
So instead we wanted to design a lean and simple firmware which will simply connect or dedicate peripherals to different domains.
And so it is the sort of simple approach to, to designing such a, such a system.
It of course need to be tested because one wouldn't believe that it would actually work without breaking all kinds of functionalities on the phone,
but it but it works. So we introduced the simple layer, and I wouldn't even call it a layer,
because it's rather a simple piece of code that assigns resources to the operating system and domains.
It simply says, you get these these calls at this time.
At this point in time, when you run, you get exclusive access to the screen,
you get this memory, you get access to GPUs, you get access to, uh, to something else.
So some of these peripherals can be shared, some of them not.
But generally the principle is that we assign instead of virtualise.
An arm actually allows you to do that.
So, uh, first thing that we that we did is if you look at this, this side here, you see that that hypervisors are gone.
So virtualisation is not needed there anymore.
Right. This is not something that we want that we want to do.
And the only thing that we did is we extended the secure monitor which runs on El L3.
So if you look at these, uh, these uh, levels, these privileged levels, uh, the L3 would be the, the highest privilege level, uh,
layer here where which we extended with, let's say, 6000 lines of code, which can then enforce this functionality that I, that I just spoke.
And these lines of code are fully transparent and open. Anyone can inspect them.
There is no there are no secrets there that that you that one needs.
So first thing that we are doing is domains run concurrently on separate call of course.
So we are not pausing Android we are not or iOS by the way this works on on iOS as well is just
that access to Apple devices is more difficult and then than working with Android devices.
And so the and the secure monitor. Right.
Also uses, um, other space controllers in order to assign memory to each to each of these, of these course.
So it's kind of a coarse grained access control in terms of scheduling one domain.
It can be any of these domains. It can be an independent domain can also be be in charge of of of scheduling these the the execution of these domains.
This also can be configured by by the user. It depends on the on the setup, on the, on the phone and the properties that you that you want.
In terms of peripherals, arm arm is also pretty good for this in the sense that your peripherals are memory mapped.
And now you can essentially use again, uh,
the address space controllers in order to grant domain specific access to, to um, to individual peripherals.
So here on this on this figure, you can see that memory is just mapped so that, uh, GPS belongs to this, uh, domain one.
And the screen domains domain two and domain three runs runs the network.
So maybe this sounds a little bit too exclusive, but when we did the analysis of the peripherals and the workflows on the phone,
it actually works pretty well in the sense that the screen, for example, is something that you need direct access to and exclusive access to.
Right? Because when you switch from one domain to another,
no other domain should see what you are doing or take input or see what you are, what you are presenting on the screen.
You also, however, for a network, maybe you can have one domain that you trust for availability.
So this domain can proxy the traffic for all the other domains.
So you don't need to need to even, even um, worry let's say about about the network that much of your traffic is end to end encrypted for example.
So this really depends on, on the peripheral and on the configuration that you, that you like.
One thing that actually surprised us, and it's always it's always a bit of a, uh, over time, you'll refine what you're what you're doing is,
is what turned out to be the biggest and the so far security issue that we, that we have identified is, uh, where interrupts.
So, uh, there are a lot of peripherals clearly that work with, with interrupts and interrupt management through, uh, a general interrupt controller.
Turned out to be the the biggest issue. So one of one of my collaborators, or one of the colleagues in on this project,
has published a number of works showing how interrupts across different trusted execution environments and so on,
can trigger attacks on those on those environments.
Right. This you can see them as, as, uh, a type of micro architectural or side channel attacks.
They're not really that's a different class of attacks,
but essentially allowing domains to manipulate interrupts that they are not in charge of causing security, security issues.
So one of one of the things that we need to to solve in this turn out to be quite interesting,
interesting work was to to then introduce this, uh, GSC protection so that we call the GSC guard,
uh, that we implemented there in order to make sure that only those domains that own those peripherals can also,
uh, work with the interrupts, uh, from those from those peripherals.
So essentially that this interrupt routeing is, is, is is protected that the owners are,
are um properly, um, um properly restricted to only what they will down and how this is done.
It's maybe a little bit too, too much of, uh, uh, to get into, but uh, luckily this GSC guard plus the,
um, the way that the GSC can be configured with these secure non-secure,
uh, uh, labelling of, uh, of interrupts and the awareness of the of the interrupt ID's of of individual, individual.
Cause you can then you can then, um, isolate this properly and and protect your protect your system.
So in a nutshell. We created a new a new architecture.
I don't think the the core idea is not that new. Clearly assigning assigning peripherals exclusively to particular pieces of code.
I don't think that's a terribly new idea in itself, but somehow going back or even I would say daring according to our given,
given the feedback that we got from the reviewers to go back and revisit an almost the default
idea that we should always virtualise all of our peripherals and and all of our resources,
and then stack things on top of on, on top of each other.
That that idea of virtualising actually didn't really solve the problem that we were trying to solve here,
which is a problem of trying to, to, uh, satisfy together satisfy all the constraints of the users.
OEMs align incentives and, and build a platform where we have a minimal or at least as,
as reduced as possible level of trust in these common components that enforce isolation.
In this case, this, uh, secure monitor running on on the R3.
So we, we with a set of these measures like the, uh, eSIM.
So secure monitor, extend it with less of less than 10,000 lines of code, uh, using these memory protection mechanisms, uh,
to isolate peripherals and memory extending, uh, on GA cigar, uh, and GSC, um,
well, essentially extended some this GSE guard reprogramming these these buttons.
We were able to to create an ecosystem where anyone is able to essentially run whatever
they want on their phone with full security isolated from their primary operating system.
And I believe that if we can and we started doing this now, if we can push this to every phone,
we can really open up, uh, open up development on each phone,
because suddenly these domains get much closer to hardware and also enable more security and sovereignty on the phone,
because now it's up to you to decide how much of the code you depend on for your critical applications.
I'm clearly is not sitting sitting, um, let's say, um, I mean, they are clearly developing their platforms.
So, um, if you're familiar with this, with this ecosystem, I see some faces.
Here they are. Um, so, um, CA for example, is, uh, is arm's, uh, confidential computing.
Uh, these are confidential computing extensions. Uh, we clearly then evolved also these design so that if in the future these can be deployed,
we already have solutions that would, um, give us the properties that I talked about just on this, on this new platform as well.
So yeah.
So I'm really hoping that this will go somewhere and that, um, all of us will be able to have, um, more secure phones, more development freedom.
And also we can we can give users, but also organisations more sovereignty over their critical workflows at the same time,
um, preserving the benefits of this exciting ecosystem.
And I, I have to say that the in terms of, um, the feedback that we got, especially at the Mobile World Congress and also in,
uh, when talking to people, uh, I'm quite excited that we, we might be onto onto something.
It's, uh, it's an interesting, uh, sort of academic and academic idea that, uh, that seems to be going, going now, uh, fully commercial.
I am clearly not done with my talk. It's a little bit too early to to let you go yet.
So this was the first part of my talk when I wanted to talk about something a little bit that touches on all of us,
and it's a it's something that we all very often interact with and, and made a, made a case for how to make it better.
But there is another topic that that worries me already for for maybe 20 years, but it seems to be more and more imminent, um, these days.
So this is most likely I mean, clearly this is an AI generated image as you can as you can imagine,
I asked I asked the AI to to generate a European city with some robots and drones in it.
So this is this is how I imagined a European city with some robots and drones.
So if you strip strip out all the technology,
it might it might look really nice and and appealing if you put all the technology in that you see here, it might be,
uh, it might be a little bit scary, maybe not the future that you want to live in, but it might be the future that that we build, we will experience.
So a lot of self-driving cars, maybe humanoid robots, maybe drones flying around delivering things, uh, making our lives generally better.
The question that you that I would ask myself, and maybe it's only me,
is if I see a drone flying over my head, or if I see a robot passing next to me.
My question is, is this robot supposed to be there? Right.
Is it going to harm me? Is this a friend or foe?
And this is a question that I would say most governments and most police forces these days are also thinking about.
Are these devices supposed to be there? How do we register these devices like we we started with cars in a very, very, uh, let's say loose manner.
And now we, we know exactly where these cars should drive with these robots and drones.
We equally want to know where they are and are they supposed to be there.
So we need to register them. They need to be able to securely and in a verifiable manner, uh, determine their location.
So and then potentially reported to us or the infrastructure needs to be able to measure their, their location.
So what we would actually want is some sort of spoofing resilience so that these devices that the locations of these devices can be securely,
uh, calculated. We want to be able to verify the locations of these devices.
And that's a slightly different property because it's about the claim, it's the location of a device that's trying to cheat.
And we also want clearly increased resilience to interference because as we have seen, especially in the case of of Gnss.
Janice. So our GPS, Galileo and so on are highly vulnerable to spoofing the different types of spoofing attacks and jamming attacks.
And these is just one of the several maps of Europe where you can see at a particular date.
This was in February this year. The locations where spoofing and jamming is is currently happening.
And this is not very surprising. If you if you have been following the news, you might see this kind of news where drones on battlefields are.
Instead of relying on on wireless communication, they are dragging wires behind them in order to be less susceptible to interference because
of the of the of the interference based attacks on the functionality of these drones.
Now, it's not only the devices that calculate their locations that are vulnerable to to these kind of attacks,
but it's also the infrastructure as well. So if you read this carefully, you will see that we are already in an era where satellites, especially,
uh, Gnss satellites, which are quite, uh, critical, are seen as a target and even a physical target.
Right? I mean, they they're even facing a potential physical disruption.
I mean, this is not very surprising, especially for for our group.
Uh, I think this is a very, very old video, right.
Uh, where we we were doing GPS spoofing.
Not sure how to make this a bit. A bit faster, but I'll try.
So. You will see GPU spoofing happening.
So here this mobile phone is in is in Zurich.
And back then what we did is we we spoofed the location from this, from this point where you saw it jump to another building in Zurich.
Now it moved a little bit. Now it's going to move to another location if you see it now moving there.
This was all done by spoofing that injected messages into the antenna of these of this phone,
and therefore shifted the perceived location of this phone.
And this doesn't only work in a small area.
We now shifted the location to Berlin. Right. So this works pretty well.
And clearly this this has been done with civilian GPS where authentication is, is um, doesn't really exist.
So you can generate genuine GPS, um, authentic looking G.P.S. signals.
This is not only a problem for mobile phones because as a as a user,
you have corrective mechanisms and you can rely on other markers in order to figure out where you are.
But this is clearly also an issue, uh, for Rob, for drones and other robots which rely on this spoofing, uh, on this, uh, location information.
Right. So here you can see a, I mean, I'm not going to play a video,
but this was done by my group of and and Jonathan in Northeastern, where they took a drone that was set to hover.
And then by injecting, uh, spoofing signals,
they managed to fully control the drone so they could essentially order the drone to go left or right by injecting appropriate GPS, uh, signals.
So why is GPS um or Genesis more, more broadly, um, vulnerable?
Well, because first of all distance. Right. It's easy to jam and overshadow and disrupt the signal.
These are these are satellites that are 20,000km away.
Uh, the the power of the of the signal on the surface of the Earth is very weak.
And this you can't easily, easily fix in in with that constellation.
Another thing is broadcast, meaning that these are broadcast only signals and they are susceptible to delays.
And these selective delay attacks can cause a location to be shifted from one to another location,
even if the if the signals are digitally signed or authenticated in some way, because, well,
the adversary can just pick up those signals and shift them to another location,
or shift them selectively and introduce delays and relays, which has been already shown in in in academic research, quite a bit.
Another thing is that the types of waveforms and modulations and time of arrival mechanisms that were built for Gnss,
at least for vanilla Gnss, they are not they're not really, um, fully resistant to the time of arrival manipulation, manipulation, attacks.
And the protection measures do not really scale. So my my argument is that we need to rethink positioning.
And we actually have a nice chance here. So. We are in an age of of Leo satellites being deployed heavily.
They are much closer to the surface of the Earth 500km.
We have great experience in running cellular networks, uh, at uh,
at the massive scale so we can leverage these additional infrastructure abilities in order
to secure those to secure positioning against both spoofing attacks and and interference.
And how how will we do that? Well, these ingredients for those who who have been maybe following this research will not be very surprising.
So we need to integrate two way ranging. So it turns out that the ability to to do two way ranging from roundtrip time
of flight ranging can actually solve the problem of secure positioning and of,
uh, location verification.
And also a denser infrastructure gives us more opportunity to rethink our, uh, jamming resilience and, uh, time of arrival protection mechanisms.
So what we are working on is to integrate terrestrial and satellite infrastructure.
Uh, so meaning work, which typically, uh, Leo Leo constellations plus terrestrial, uh, infrastructure in order to solve, solve this problem.
So the first thing that you have to think about in this space and, and this is,
of course, a very high level, high level talks, I can't go into many details is that.
So if you look at the broadcast systems like DNS and also like some of the
some of the Leo constellations that are simply broadcasting for positioning,
you can't really prevent spoofing. So that's really not a solution because of these selective delay attacks that I mentioned.
But what you can do instead,
you can do around the time of flight distance measurements that you can then in addition protect against distance reduction attacks.
So if you can prevent distance reduction attacks, meaning that an adversary cannot reduce the distance,
but only large, he just happens that within these this kind of geometry, like a,
like a this pyramid here, if you do this from, from several, uh, vantage points,
you can have a guaranteed provable, uh, secure positioning system and even location verification system.
So and this is a result that's quite old. It's from 2004 2005.
Recently a group of people are sitting at this point, and, um, our students want us.
We're are extending this kind of an an idea with what they call trick.
Where they are combining essentially broadcast with a response to so a broadcast from one once one of the systems.
So for example NSE or Leo and then a respond a response to a two terrestrial system forming instead of these circles that constrain the geometry,
they they create ellipses in order to and define a region within which spoofing is not is not possible.
Right and into which spoofing is not possible either.
So this is this seems like relatively, relatively simple geometric thinking,
but there's actually quite interesting, interesting academic work behind it.
So. But in order for these geometries to work and give us secure positioning, we need we need something else.
We need to be able to protect these two ways ranging against distance reduction attacks.
So if you have a satellite and, uh, and a drone or two drones running challenge response protocols that are authenticated,
one would believe that these are sufficient to prevent distance reduction attacks, but they're really not.
So we know from from the research literature that that specially crafted signals injected by the adversary into these two devices,
measuring a distance, uh, can actually shorten the distance that is measured between these two devices.
If we if an adversary can do that, there is practically no help in in building a secure positioning system.
So we need to solve this problem. So how can this happen?
So if you if you look at a bolt here, uh, a pulse which is wirelessly transmitted over a wireless channel when it.
When it arrives at the receiver, it's going to be somewhat smudged, right?
So it's going to be spread by the by this channel because these wireless channels are quite complex.
And not only that, it's going to be spread, but counter-intuitively,
the the time of arrival of this smudged pulse will not be the strongest peak that you see here, but it might be the one that's that's before four.
You have to essentially determine which one is it,
and that that's where a lot of crafting might go in terms of building these kind of arranging systems,
which one of these earlier peaks that come before the the strongest peak is actually the one that determines the true the true distance.
And by injecting signals in such a way that you can create this even earlier peak.
You will be able to shorten the distance. So that's intuitively how this works.
Not not very precise, but intuitively how some of these attacks work.
And this was one of the attacks that we that we did on, on, on an ultra wideband ranging system where we,
we paired, we looked at the, the ranging between an an NXP chip and an iPhone.
So on an NXP ultra wideband chip and iPhone where we when we turned our spoofing, we were able to bring a distance that was measured at 8m to 0m.
So this is clearly. And how did we do that?
Well, we actually didn't know any of the, of the keys or, or random sequences that were exchanged between these two devices.
And we injected what was essentially another random sequence into the on top of the packets that were being exchanged by these two devices.
And we managed to cause those early peaks to appear in the in the receiver and therefore trigger a shorter, a shorter distance measurement.
I mean, the measurement of a shorter distance. He's actually a very, very fresh out of the print result.
Um. Where we have recently shown it's a very simple kind of kind of result.
Again, very counter-intuitive. So if you see here on the left, there are you can use in a narrow band, uh, system.
You can actually use a negative group delay.
Um, filter that can.
I'm not sure if I have a. Yeah. So here this blue this blue signal is the, um, is the signal that should come out of the that should arrive at the,
at the receiver if we didn't introduce our attack.
Right. So instead what we did is we created we, we implemented a filter that created this red.
Red curve, but it seems as if it has arrived earlier.
Right. So if you look at this envelope here, and if you measure the time of arrival of that envelope, you will measure an earlier time of arrival.
And how did we do that? Well, this filter essentially, uh, aggressively amplifies these,
these amplitudes here and then suppresses them later in order to create this shape without knowing what's coming,
without knowing which signal, which which signal, these come.
So it's a very, very elegant way to reduce a measured a measure distance by manipulating,
uh, by manipulating, using in this case, something that wrote you. Another attack that that comes from, uh, already from 2006.
Is what's called an early detect, late commit attack. Uh, in this case, I illustrated on ultra wideband, right where you have a drone sending some,
some pulses to a drone, and they are supposed to arrive as indicated here.
The attacker wants to transmit those pulses earlier, but doesn't know what they are in advance.
Cannot guess them. Right? So they are completely random. So what the attacker can do instead the attacker can send something in advance.
Some random random garbage within the slots that he wants.
And then when he learns. A part of the signal that that, um, that the sender transmitted.
He sort of he generates the remaining part of this, of this signal.
And now some of the time of arrival systems will react in the following way.
They will say, hey, you know, maybe half of the of this symbol is messed up,
but the other half shows shows enough evidence that this is a correct, that this is a correct symbol.
And in and when summarised. I think this is a fine symbol.
And of course, this kind of behaviour that you see here, it's a bit exaggerated but can happen on the real wireless wireless channel.
So you end up advancing again and shortening a distance.
So how can one protect against these physically? Uh, attacks.
So basic protections, like a secret spreading codes can help?
Not entirely, but they can. They can assist there. There is a lot of work now.
There was a work work from Apple, for example, in the ultra wideband space,
showing how effectively using spreading spreading codes across different sequences
can potentially mitigate some of these attacks in the context of ultra wideband GPS.
Uh is introducing camera, which are physical layer markers, um, which are some sort of punctured codes,
right, in order to, to detect on the physical layer whether weather signals have been manipulated.
Uh, in ultra Wideband, we have we have done a lot of work securing that even mentioned resulting in a spinoff company and product in up, uh, in Wi-Fi.
We have we have mechanisms for that that are being now introduced in standards, the same in Bluetooth.
And well, that's something that I already mentioned how this could be and this could be done.
So in a nutshell, we have different technologies, geometries and ranges that we could potentially use to derive a position of a device.
But at the at the core of it for each of these technologies is how do we protect
the time of arrival in order to avoid this kind of time of arrival manipulations,
because at least against distance reduction, because if we can prevent distance reductions,
distance enlargements will be prevented by the geometry itself.
So we need to focus on that.
And if you look at different technologies that are being used for ranging, uh, you can of course pick on which one you want to work.
We worked already on Ultra wideband, on Bluetooth, uh, on 5G,
and most recently we introduced a new a new system that we built specifically for, uh, space.
So for arranging with, uh, Leo satellites, where we then focussed on all of the M, uh, modulation because that's, uh, modulation.
That's, that's being used in, in a lot of communication systems, um, including with Leo and, and of course, this is now an overloaded overload,
this slide of all the things that one needs to do in this space in order to in order to make this work right from the start,
designing the waveforms that you want to use to design the packets and making sure that, uh,
that you have a time of arrival verification that secure and provably secure and so on.
I'm going to give you an intuition behind behind, um, those those results.
So this is the intuition. No. So what are we doing?
For those of you who don't? Who are familiar with all of the modulation or not?
I mean, it's essentially a frequency kind of embedding.
And with an inverse Fourier transform, you get, uh, you get the, um, the time, the time domain signal, then you, then you transmit and.
What did we actually do? We took two consecutive symbols in the OFDM.
Uh, in the URL of the a manipulation encoded in the in the frequency domain.
And we created, uh, a verification,
a verification function that is going to test whether the wireless channel is consistent across those two, those two symbols.
And what does this on on a high level test. This test whether the the distortion of the wireless channel is plausible or not.
So if it's plot if it's if it's inconsistent across these two consecutive symbols,
this means that most likely there is there is some sort of an intervention by by
an adversary and not an expected and expected behaviour of the of the channel.
So, um, yeah.
And this in the, in the, um, in this constellation diagram looks looks like this.
So the. Typically when you are when you decode these symbols,
what you expect is that due to the channel changing the phase and the amplitude of your of your arriving signals,
you will need to do some form of a of a compensation.
So if you if you can test that this compensation is inconsistent across two symbols, you can let's say build on top of that.
And, and then um, uh, have your time of arrival verification function.
And for that, of course, we produced the proof that is in our, in our research research work.
But of course, you know, security, we need to, uh, argue through proofs that we, that we write in papers.
But implementation wise, we wanted to see if such ideas could actually work.
And for that we have built first then in lab in lab setup.
Right. This large box here is essentially emulates a wireless signal between the ground and and the satellites.
So so this is a full a full blown, uh, satellite link simulator, right,
where you can plug in your, your signals from the ground and from the satellite and back,
and then test alongside with all the constellations and all the Doppler shifts and everything that you have to cope with.
Right, in order to to test whether this type of modulation and this type of verification function can actually survive such channels,
and we have shown that functionally it can. Right.
We were not very happy with this because we said we we need to go out and actually test this.
And um, and then we went to, uh, to a tunnel because transmitting outside is not so easy if you,
if you are, um, getting licenses to transmit in certain bands, it's not so obvious.
A tunnel clearly is not a channel that's, that's representative of a satellite channel.
You don't have a tunnel to the up in the sky, but we wanted to functionally test across 500m where there are actually set up works.
And so what you can see at one end of the tunnel, there was uh, there is a, there's one, uh, transceiver, another one here on this cart.
And, uh, and what you don't see students pushing this cart down the tunnel.
And as a result, you can you can see this distance actually changing, being being reduced as a result of this, of this approach.
And then when they pull back you will see the distance, the distance increase.
Increase back. Um back to the.
Yeah. Mhm. And of course we are not happy with that either.
So we did the test in the lab.
We did the uh terrestrial tests and we will do more open space tests.
But we are also happy that ESA uh, will allow us to deploy our, our design within the, um, the cyber Cube.
So there was a competition, and there will be.
And a European Space Agency launched satellite that will implement several projects, including, uh, our own,
uh, where we will then perform our experiments from the satellites down to the down to the ground.
So in summary, I believe that we need to change the way that we that we work on,
on these positioning systems in the sense that we need to change the the reference that only broadcast the broadcast,
the only systems are sufficient, that we don't need terrestrial infrastructures to be built in our cities.
I think we do. I think we will need more robustness in this space.
Otherwise we will see a lot more attacks that involve spoofing of locations, duping on on own locations, by by devices.
So we need to build. We need to be ready build fundamentals for, for for this uh, for this particular problem space.
And if we can do that, maybe we'll have a more secure future.
Um, of course, it's easy to be pessimistic about that, right?
Most likely, how these things develop is that you first need attacks and problems to happen and then deploy these, these kind of solutions.
But let's see, maybe we we get ahead of a curve. Uh, there is some hope because there are already a number of calls by, by relevant European,
uh, and global entities calling for secure positioning to be, to be deployed.
And also these, uh,
the effects of the of the recent wars where spoofing and jamming has been quite prevalent are showing how relevant this topic is, is becoming.
Uh, so final final musings for my from my side when it comes to generally system design and and
security research is that I think we we can be really bold in hardening our infrastructures.
I think it doesn't require us to be to, to design everything from scratch.
I think we can integrate technologies. Uh, our choice of OFDM is it's not only a choice to go for OFDM,
but we are clearly looking for integration within existing 5G and other other
technologies to towards and to effectively simplify the implementation of of such um,
protection measures into existing, uh, ecosystems in the same way for the sovereign smartphone.
What we want wanted to do is to avoid the trap of of being exclusive.
We wanted to be on a platform that's actually open to to everyone,
including large ecosystems, because this is not an, uh, this is not a fight against someone.
It's a it's a, it's a fight to have systems that we can actually control, either as a user or as as as as communities.
And so of course, of course, that I did all of this alone.
Um, and, uh, so these are some, some of the people on, uh,
that I want to acknowledge that work quite hard on some of these, uh, projects that you have seen.
And with this, I, I thank you.