Peter Singer, a leading US defense analyst, who headed Barack Obama’s defense policy team during last year’s presidential campaign, believes that the world is on the brink of a “robotics revolution” in military combat that will have profound social, psychological, political and ethical effects.
The US had invaded Iraq in 2003 with just over a handful of unmanned aerial drones, and no unmanned ground vehicles, he said. Today it used more than 7,000 drones in the air, and more than 12,000 unmanned ground vehicles capable of combat.
Their use in warfare was a massive development in human history, he told the Lowy Institute in Sydney, via videolink from Washington.
The use of robots in the war zone is not spontaneous – it is in fact mandated by the US Public Law 106-398 which sets a goal of one-third of all ground combat vehicles to be unmanned by 2015.
Last year, the first transformer-like armed robot MAARS (Modular Advanced Armed Robotic System) was set to be deployed to fire in combat:
“It can be changed from one mission setup to another in short order,” says Charles Dean, the Foster-Miller company’s senior program manager for advanced robots. Operators can alter the machine’s treads, drive system, weaponry and even its dimensions.
“Government has been working with us over the last 18 months to develop and provide an innovative and evolutionary approach to combat situations that address the battlefield of the future,” said Dr. William Ribich, President of the Technology Solutions Group, QinetiQ North America.
Let’s have a look at the software architecture that drives MAARS robot.
Built by Applied Perception, part of the QinetiQ North America Technology Solutions Group, the software called Soldier Universal Robot Controller (SURC) enables operators to simultaneously task, monitor, and teleoperate multiple unmanned robots from a single control station.
Its User Interface can apparently be integrated into a handheld control unit, or as user application running on a notebook, e.g. under Ubuntu Linux, as seen on the image below:
SURC system consists of several elements that are depicted in the following scheme:
Its core modules are responsible for keeping track of the robots, path and mission planning, and storing data about the existing objects.
An interesting aspect of this architecture is that SURC plugs into JAUS (spelled as “jaws”), Joint Architecture for Unmanned Ground Systems. SURC’s transport component is responsible for interfacing SURC with JAUS.
JAUS is an open message-passing architecture that unifies multiple computing nodes and provides the means of their inter-communication. It defines the hierarchy structure of the elements (subsystems, nodes, components), defines the standard for the message that is passed from one component to another, and defines other requirements such as mission isolation, platform, hardware, and operator use independence (just like the Web).
JAUS dictates the use of UDP (User Datagram Protocol) as a communications protocol between the nodes. The messages are packed into JAUS message structure and are handled with the node managers according to the commands specified in these messages. The traffic is forwarded via the port 3794, the “JAUS Robots” port.
As any other software architecture, it will very likely be a matter of time until JAUS is probed for an unauthorized access. The rule of thumb here is the bigger the target and its importance, the more lucrative it is and thus, the larger incentive and motivation will be there to exploit it. It won’t be a question of “how”, it will be a question of “when”.
Let’s try to imagine for a moment in science fiction terms what attack vectors against JAUS are possible, and what an unauthorized access to it could result in.
In theory, an interception of traffic between the transport component of SURC and the JAUS platform that connects it with the in-field robots’ node managers, can be exploited.
Firstly, a UDP flood attack may render the whole fleet of robots useless.
Secondly, an injection of malcrafted packets into the link between SURC and JAUS may potentially change the mission goals, starting from the civil casualties increase, and finishing with hijacking the whole fleet of UxV and then re-recruiting it against the original command centre. This could potentially be exploitable due to the platform, hardware, and operator use independence declared by JAUS open architecture standard.
Thirdly, JAUS architecture could also potentially be attacked with the malformed exploits transmitted via port 3794, either with the purpose of gaining full administrative control over the node managers or simply causing denial-of-service by crashing their software.
Of course, these attacks are very unrealistic right now. So the reader should consider these insinuations a pure fantasy. But if the reader thinks for a moment of how many platforms were supposed to be secure by design, but could still easily be exploited; if the velocity of the progress and the scale of attractiveness for the attackers are all accounted, then it might be easier to imagine how in a few years time all robotic machines would have to be patched every Tuesday: