Securing the Navigation of Unmanned Marine Systems

1. Securing Navigation of
Unmanned Maritime
Systems
Tope Omitola, Jon Downes,
Gary Wills, Mark Zwolinski,
Michael Butler
1

2. Motivation
• USV Autonomy - Navigation Aids for Safety and
Awareness
• Autonomous USVs must avoid ships, docks, floating
debris
• Secure navigation aids - to avoid obstacles
• Secure navigation aids - for situational awareness
• Question we address in this paper: “The Assurance
of security of autonomous navigation and
control in Maritime systems, and USVs in
particular”
• Preliminary work reported, more work is being done in
the area
• Secure navigation aids Key to Situational Awareness

3. Unmanned Surface Vehicles
and Autonomy
• USVs are maritime-based surface vehicles that have different levels of
autonomy
• 6 levels of Autonomy*:
– Level 0: Manned
– Level 1: Under Operator control
– Level 2: Under Directed control of Operator
– Level 3: Delegated; Control is from USV,
Decision-making shared between Operator and USV
– Level 4: Monitored; USV senses
environment. Operator may monitor events
– Level 5: Autonomous; USV senses and reports state of environment, Operator may
monitor events
* Maritime UK. "Being a responsible industry - an industry code of
practice" 2017 Report
3

4. USV Navigation Vulnerabilities and
Possible Hazards
• Global Navigation Satellite Systems (GNSS), e.g. GPS, GLONASS, COMPASS,
GALILEO
• Vulnerabilities
– Very weak signals (-160dB W)
– Signals not encrypted
– Unintentional and Intentional Interference
• Possible Hazards
– Complete failure of USV's GNSS receiver
– Presentation of hazardously misleading navigation data
• Possible Attacks
– Spoofing: broadcast of false signals
– Jamming: intentional interference of signals
– Meaconing: intentional interference & rebroadcasting
signals to confuse
4

5. Security and Hazard Analyses of
the Navigation Component of USVs
• Hazard Analysis important for certifying systems safety
• Traditional Techniques, e.g. HAZOP, FTA, only focus on single
component’s failures and failure events
• Cyber-Physical Systems, such as USVs, have inter-component
interactions, failures and failure events
• We use STAMP and STPA for security and hazard analyses.
• Developed at MIT, both have good track records in inter-component
safety and hazard analyses
• In STPA, failure events, and Accidents, are caused by safety
constraints not successfully enforced
5

6. STAMP’s four components of Controller, the Controlled entity,
Actuators and Sensors
6

7. STAMP’s 4 possible causes
of Accidents
• A control action required for safety was not provided
• An unsafe control action was provided
• A control action required for safety was provided too
early or too late or in the wrong sequence
• A control action required for safety was stopped too
soon or applied too long
7

8. (Some of Possible) Accidents
and Hazards Analyses of Navigation Component
ACCIDENTS HAZARDS
A1. Unavailability of Navigation Module (NM) H1.1 NM receives continuous stream of un-
usable GNSS signals via a jamming attack
H1.2 Malevolent manipulation of hardware
and software layers of NM to alter GNSS data
interpretation
A2. Un-authorised disclosure of GNSS
information
H2. There is un-authorised disclosure of
GNSS information
A3. Received GNSS information are not
genuine
H3.1 GNSS information have been
intentionally altered via a spoofing attack
H3.2 NM receives replayed GNSS signals via
a meaconing attack
H3.3 GNSS information have been un-
intentionally altered (probably due to natural
accident)
A4. Users' Psychological Error H4. Over-reliance of users on provided GNSS
data
A5. Unintentional Radio Frequency (RF)
interference
H6. Noise from nearby RF transmitters
interferes with genuine GNSS signals
8

9. STPA Methodology
9
Control Actions Not Providing Causes Hazard Providing
Causes
Hazard
Wrong Time or
Wrong Order
Causes Hazard
Stopped Too Soon
or Applied Too
Long
NM assures
authenticity of
its software &
hardware
components
UCA1: Malevolent components
installed in NM [H1.2]; UCA2: Unauthorised
principals able to alter GNSS data
interpretation [H1.2, H2, H3.2]
None Same as UCA1 &
UCA2
Same as UCA1 &
UCA2 (Stopped
Too Soon)
NM mitigates
jamming attack
UCA3: Denial of Service attack (of NSS data)
[H1.1, H5]
None Same as UCA3 Same as UCA3
(Stopped Too Soon)
NM provides au-
thorised disclo-
sure of GNSS data
UCA4: Un-authorised entities able
to elicit USV position (information leakage)
and/or able to replay
GNSS information (traffic analyses).
Possibility of taking control of USV &
sabotage mission [H2, H3.1, H3.2]
UCA5: Tampering, i.e., deliberately
destroying or corrupting data [H2, H5]
None Same as UCA4 Same as UCA4
(Stopped Too Soon)

10. Next Steps and Future Work
• Very preliminary investigation of STPA to CPS Autonomy -
Fruitful area of work
• How can we include USV control algorithm processing GNSS data
in STAMP/STPA
• Taxonomy/Hierarchy of Hazards and Risks
• Constructing Safety Constraints to mitigate or stop unsafe control
actions
• Use Event-B to model control actions and safety constraints to
develop framework for security analysis for autonomous
navigation of unmanned marine systems
– Event-B is a formal method for software system design that
provides strong support for rigorous verification using
mathematical techniques
10

11. QUESTIONS
• t.omitola@ecs.soton.ac.uk
11