Is the future of operations just ‘Google Maps’? What new vulnerabilities does this generate?
12 Sep 24
Electronic Warfare
Andy Rogerson, our EW & Electromagnetic Spectrum Operations Training & Consultancy Expert, muses over the operational utility of apps that we take for granted and how they might be exploited.
Imagine you want to drive from your house to visit a friend who has recently moved (i.e. you don’t know how to get there from memory yet). It’s reasonable to suggest that many individuals would now reach for their mobile phone, with Google Maps being a potential routine application to use - although there are other alternatives available.
It’s a simple matter to just enter the departure and destination addresses, to then let the algorithm calculate the optimal route which will incorporate user preferences. If you intend to leave now, it can base its route on real-time information. If you intend to leave at a specific time in the future, you can also enter a departure or required arrival time and have the app base its routing on historic data. You can then take that same phone with you, connect it to the car and have the route display real-time instructions as you track progress.
And if there is a road traffic accident on your route? No problem - the app can identify the potential issue and propose alternative routing to minimise delay and optimise the journey. This suggests that the app algorithm could be a form of artificial intelligence reinforcement learning and is designed to consider efficient journey time as a favoured parameter.
The app can also identify road blockages - due to several data inputs - all of which remain transparent to the user. This may include sensor and mobile phone data from other devices stationary at the blockage, as well as other background running apps, such as GPS, that will identify that they are stationary and share that fact with the cloud. The important point is that the map/route app informs the user of a likely problem and has already attempted to resolve a solution simultaneously using data which is transparent to the user.
To calculate the initial route, the phone requires a data connection. Once calculated, this route can then be stored for offline use, or if a data connection is maintained, the re-route efficiencies are made available.
Let’s now consider an equivalent military function: Aircrew flight planning for an interdiction mission
Departure and destination (i.e. the target) are known. The route can then be plotted based on preferences, including known enemy assets and their locations, presented radar cross section of the platform to known enemy sensors, loadout, available fuel state and endurance. Of course, it can be expected that the operational flight plan requires more data input, but so far, the planning similarities are reasonably comparable.
The aircrew walk to the platform, load in the plan and then depart. However, short an interval, time has now elapsed between the planning data input and reality. That temporal difference means that the expected adversarial situation may be different to that which will be faced in reality. Changes en-route don’t tend to include road-traffic accidents (RTAs) for interdiction missions, but pop-up, previously unlocated surface-to-air missile (SAM) threats might be a reasonable dynamic input.
Let’s say that a SAM threat is detected ahead on the platform’s planned route. Detection of which might come from the platforms organic sensor suite or be detected by another asset which shares the SAM location via datalink. The aircrew must now determine the severity of the threat and take appropriate action, which may include flying off the pre-planned route. Traditionally, the aircrew might now be mentally calculating dynamic re-routing, fuel state etc.
Why not build Google Maps into the platform?
The platform could be provided with sufficient data connections to permit spatial and temporal awareness and knowledge of its own performance. The platform itself could then propose a new route based on its knowledge of its own Radar Cross Section (RCS), and how much it could present to the threat.
Data provision might incorporate knowledge of terrain data and propose a re-route that places a high ground barrier between the threat and itself. It could choose to incorporate knowledge of its fuel state and endurance to ensure the most optimum diversion and route re-establishment for continued mission success.
It is true that the platform might require constant data, but such connections already exist in the form of Link-16 or MADL-type datalinks. Whilst these datalinks may not be appropriate forms of connectivity for future app-like systems, the precedent is already there for persistent data connectivity.
What perhaps is missing is the ability of the platform itself to ingest messages from a whole host of differing inputs and to interpret them ‘behind the scenes’ transparently to the operator to aid dynamic mission optimisation. If the platform could run its navigation in an app-like way, then it could incorporate these inputs.
In many ways, the phone’s performance in this limited example could potentially be far ahead of tactically navigating the traditional platforms I personally have flown. What may also be interesting however, is the counter to such potential app-like incorporation into platform development and operation.
An example: Simon Weckert’s traffic jam
German Simon Weckert created a traffic jam in the name of art, but he did so without a car, or by setting up any physical block. His blockage was created virtually, in Google Maps (not in the physical world) by pulling a handcart containing 99 second-hand smart phones along a road. This caused the mapping algorithm to incorrectly conclude that 99 slow moving smart phones must be caused by multiple buses moving extremely slowly. Whilst only a virtual effect, it created real, physical consequences for other mapping app users who were diverted. You can read more about it here.
As contemporary sensors utilise app-like technologies, sharing ubiquitously across combat clouds to generate spatial awareness and intelligence-fused decision making and real-time tasking, how could any new reliance on them be exploited?
Comprehension of the inner workings of an algorithm could permit rational action against it. Could extensive use of a combination of pop-up real and physical, and electromagnetic decoys be employed to deliberately create a predictable reaction?
How could the ‘Weckert-effect’ (you heard it here first!) be used to shape and control an adversary’s real-world, physical actions and responses by deliberately manipulating the electromagnetic and virtual spaces?
Such phenomena could result in the need for improved sensor fidelity, potentially across a robust and secure network of platforms to tell canny decoy from real. Mission data may need to be updated dynamically, as threats shape around a targeted platform, and all this requires extremely robust and rapid data sharing. Overall, it emphasises the need to dominate and assure the information space.
So, what do you think? If you’re interested in debating this (and much more!) then enrol onto our Fundamentals of Electromagnetic Warfare training, with the next course taking place from 11th – 15th November 2024.
The course is suitable for both military and civilian personnel with a role in the design, development and acquisition or operation of EW capabilities – or just for those with an active interest in the subject. For more information or to book your space, get in touch at [email protected].
Latest News
Inzpire holds first Annual Reception at immersive London hotspot
03.10.24
Inzpire
On 2nd October, we were delighted to host our inaugural Annual Reception at London’s award-winning gallery, Frameless.
Need Help?
Our team are here to help. If you have any questions, no matter how big or small, please get in touch.
+44 (0)1522 688231
.(JavaScript must be enabled to view this email address)