Mesh Security: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (categorization)
(→‎Introduction: Corrected some awkward wording in the first sentence.)
 
(17 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{OLPC}}
== Mesh Security Analysis ==

== Mesh Security ==

=== Mesh Security Goals ===

Mesh Security are the set of security measures taken to:

# [[Mesh Security#Mesh Security - Robustness|Prevent service disruption]]
# [[Mesh Security#Mesh Security - Access Control|Prevent unauthorized access the network]]
# [[Mesh Security#Mesh Security - Confidentiality|Ensure confidentiality]]

Each of these security areas is discussed in a subsection below.

== Mesh Security - Robustness ==


=== Introduction ===
=== Introduction ===


The purpose of the mesh subsystem is to transfer data between mesh points over
This analysis focuses on the risks that may prevent the mesh subsystem from performing its duty: to transfer data between mesh points over a partially connected network.
a partially connected mesh network. This analysis attempts to categorize the
threats that would prevent the mesh subsystem from performing this duty.


It is important to keep in mind that mesh networks, due to the lack of underlying infrastructure and the use of a shared medium, are inherently insecure. For instance, there is no possible defense against disruptions of the physical medium with jammers and similar equipment. In the analysis below we focus on the measures that need to be adopted to prevent attacks performed by the xo's themselves, as such attacks would be the easiest to execute.
It is important to keep in mind that mesh networks, due to the lack of
underlying infrastructure and the use of a shared medium, are inherently
insecure. For instance, there is no possible defense against disruptions of the physical medium with jammers and similar equipment. In the analysis below we focus on the measures
that need to be adopted to prevent attacks performed by the xo's themselves, as such attacks
would be the easiest to execute.


The current implementation of the mesh in OLPC does not provide mechanisms to control access to the network nor to ensure confidentiality. These measures may be implemented in the future and discussed in sections [[Mesh Security#Mesh Security - Access Control|Access Control]] and [[Mesh Security#Mesh Security - Confidentiality|Confidentiality]]. Thus this analysis does not cover mitigations to attacks on privacy or unauthorized network access.
The mesh subsystem in OLPC does not provide mechanisms to control access to the
network nor to ensure confidentiality. Thus this analysis does cover
mitigations to common network attacks such as eavesdropping or unauthorized
network access. It is assumed that those services will have to be provided by
higher network layers.


The threat categorization that follows is based on [1] and [2].
The threat categorization that follows is based on [1] and [2].
Line 25: Line 29:
==== Resource Depletion ====
==== Resource Depletion ====


* Traffic flooding (overload the medium)
===== Traffic flooding (saturate the medium) =====


As mentioned in the introduction little can be done against this.
As mentioned in the introduction little can be done against this.


'''Mitigation:''' TODO: Can the xo be used to flood the medium and use up all the channel capacity?
<font color=green>Mitigation:</font> TODO: Can the xo be used to flood the medium and use up all
the channel capacity?


* Directed traffic flooding (fill up victim's queues)
===== Directed traffic flooding (fill up victim's queues) =====


'''Mitigation:''' TODO
<font color=green>Mitigation:</font> TODO


==== Flow Disruption ====
==== Flow Disruption ====


* Node impersonation (MAC address spoofing)
===== Node impersonation (MAC address spoofing) =====


Nothing prevents assigning a different MAC address to the wireless interface. This address will be used until the laptop is rebooted. An attacker can impersonate a victim and prevent her from receiving traffic.
Nothing prevents assigning a different MAC address to the wireless interface.
This address will be used until the laptop is rebooted. An attacker can
impersonate a victim and prevent her from receiving traffic.


'''Mitigation:''' The destination sequence number could be used to detect that there are duplicate MAC addresses within range.
<font color=green>Mitigation:</font> The destination sequence number could be used to detect that
there are duplicate MAC addresses within range.


* Data tampering by forwarding nodes.
===== Data tampering by forwarding nodes. =====


Forwarding nodes could modify data frames so that the frame is considered invalid and dropped at destination.
Forwarding nodes could modify data frames so that the frame is considered
invalid and dropped at destination.


'''Mitigation:''' Forwarding is done at firmware level and users have no access to it. The host cannot modify forwarded traffic.
<strike><font color=green>Mitigation:</font> Forwarding is done at firmware level and users have no
access to it. The host cannot modify forwarded traffic.</strike>
:In addition to firmware modifications, there will exist non-XO hardware with the ability to generate and receive mesh packets.


* Nodes behave normally during route discovery but drop data traffic.
===== Nodes behave normally during route discovery but drop data traffic. =====


'''Mitigation:''' Forwarding is done at firmware level and users have no access to it. The host cannot modify forwarded traffic.
<font color=green>Mitigation:</font> Forwarding is done at firmware level and users have no
access to it. The host cannot modify forwarded traffic.


: A node cannot be permanently configured to respond to drop all data traffic ''while still responding to RREQs''. But a node that constantly clears it forwarding table would '''behave normally during route discovery but drop data traffic'''. So this mitigation will only hold if ''iwpriv msh0 fwt_reset'' is disabled.


=== Attacks on Flow of Routing Traffic ===
=== Attacks on Flow of Routing Traffic ===


* Modifying the metric in route requests/route replies.
===== Modifying the metric in route requests/route replies. =====

<s>This is perfectly possible using the ''iwpriv fwt_*'' interface into the
forwarding table.</s>

<s><font color=green>Mitigation:</font> Disable ''iwpriv fwt_*'' commands before release?</s>

Changes to the forwarding table via the ''iwpriv fwt_*'' interface will not affect the metric of transmitted route requests/route replies. So the mitigation is:

<font color=green>Mitigation:</font> Firmware does not allow changing the advertised cost for routes (only changes that affect locally originated traffic are allowed).

===== Invalidating the route table in other nodes by advertising incorrect paths. =====

Same as previous. Furthermore, the mesh does not support proxy route replies, so intermediate nodes cannot advertise forged routes on behalf of the destination node.

===== Refusing to participate in the route discovery process. =====

<font color=green>Mitigation:</font> A mesh point cannot ''leech'' the mesh: in order to send
and receive traffic it must also propagate data and route management frames
for other nodes.

===== Generate false route error messages =====

Route error messages propagate information about invalid routes. False route
error messages could cause the deletion of valid routes, which would have to
be rediscovered.


<font color=green>Mitigation:</font> Route error messages are generated by the firmware and
This is perfectly possible using the ''iwpriv fwt_*'' interface into the forwarding table.
cannot be forged from the host.


== Mesh Security - Access Control ==
'''Mitigation:''' Disable ''iwpriv fwt_*'' commands before release?


The current mesh implementation only provides an Open Access control policy,
* Invalidating the route table in other nodes by advertising incorrect paths.
where all the mesh nodes will accept and forward traffic on behalf of any other
node. Open Access is particularly useful in mesh routing, as the value of the
mesh generally increases with the number of users.


But there may be situations where some form of access control is useful, for
Same as previous.
instance when there is a high density of users in a small area. In that
situation it may be better to only allow access to a smaller subset of
authenticated users.


=== Access Control Policies ===
* Refusing to participate in the route discovery process.


Based on these considerations, these are the three possible access control
'''Mitigation:''' A mesh point cannot ''leech'' the mesh: in order to send and receive traffic it must also propagate data and route management frames for other nodes.
policies that we envision:


==== Open access ====
* Generate false route error messages
In open access any mesh node is allowed to participate in node discovery. This
allows greater connectivity between mesh nodes. However this model requires
a stronger immunity against service disruptions (see
[[Mesh Security#Mesh Security - Robustness|this section]])


==== Authenticated Access only ====
Route error messages propagate information about invalid routes. False route error messages could cause the deletion of valid routes, which would have to be rediscovered.
Mesh nodes involved in forwarding should be authenticated with a common shared
secret. This ensures that rogue MPs can’t subvert mesh discovery. However it
reduces the connectivity of the mesh as other MPs not part of the same group
cannot be part of the mesh.


==== Multiple Authenticated access ====
'''Mitigation:''' Route error messages are generated by the firmware and cannot be forged from the host.
In this scenario mesh nodes can have multiple shared secrets. Therefore each
mesh node can, based on the mesh ID or other information, use a different
shared secret to join the mesh. The MP can be part of multiple mesh networks
and can forward packets from one mesh to the other. This model follows the
"friend of my friend is my friend" model.


== Mesh Security - Confidentiality ==


''If you have an opinion on this, please use the Discussion page''
=== Bibliography ===


== Bibliography ==
[1] "Techniques for Intrusion-Resistant Ad Hoc Routing Algorithms (TIARA)", Ramanujan R. et al., ''MILCOM 2000. 21st Century Military Communications Conference Proceedings'', 2000


[1] "Techniques for Intrusion-Resistant Ad Hoc Routing Algorithms (TIARA)",
[2] "Intrusion Detection in Wireless Ad-Hoc Networks", Mishra A., Nadkarni K. and Patcha A. ''IEEE Wireless Communications'', February 2004
Ramanujan R. et al., ''MILCOM 2000. 21st Century Military Communications
Conference Proceedings'', 2000


[2] "Intrusion Detection in Wireless Ad-Hoc Networks", Mishra A., Nadkarni K.
and Patcha A. ''IEEE Wireless Communications'', February 2004


[[Category:Network]]
[[Category:Network]]
[[Category:Security]]

Latest revision as of 03:02, 9 September 2008

  This page is monitored by the OLPC team.

Mesh Security

Mesh Security Goals

Mesh Security are the set of security measures taken to:

  1. Prevent service disruption
  2. Prevent unauthorized access the network
  3. Ensure confidentiality

Each of these security areas is discussed in a subsection below.

Mesh Security - Robustness

Introduction

This analysis focuses on the risks that may prevent the mesh subsystem from performing its duty: to transfer data between mesh points over a partially connected network.

It is important to keep in mind that mesh networks, due to the lack of underlying infrastructure and the use of a shared medium, are inherently insecure. For instance, there is no possible defense against disruptions of the physical medium with jammers and similar equipment. In the analysis below we focus on the measures that need to be adopted to prevent attacks performed by the xo's themselves, as such attacks would be the easiest to execute.

The current implementation of the mesh in OLPC does not provide mechanisms to control access to the network nor to ensure confidentiality. These measures may be implemented in the future and discussed in sections Access Control and Confidentiality. Thus this analysis does not cover mitigations to attacks on privacy or unauthorized network access.

The threat categorization that follows is based on [1] and [2].

Attacks on Flow of Data Traffic

Resource Depletion

Traffic flooding (saturate the medium)

As mentioned in the introduction little can be done against this.

Mitigation: TODO: Can the xo be used to flood the medium and use up all the channel capacity?

Directed traffic flooding (fill up victim's queues)

Mitigation: TODO

Flow Disruption

Node impersonation (MAC address spoofing)

Nothing prevents assigning a different MAC address to the wireless interface. This address will be used until the laptop is rebooted. An attacker can impersonate a victim and prevent her from receiving traffic.

Mitigation: The destination sequence number could be used to detect that there are duplicate MAC addresses within range.

Data tampering by forwarding nodes.

Forwarding nodes could modify data frames so that the frame is considered invalid and dropped at destination.

Mitigation: Forwarding is done at firmware level and users have no access to it. The host cannot modify forwarded traffic.

In addition to firmware modifications, there will exist non-XO hardware with the ability to generate and receive mesh packets.
Nodes behave normally during route discovery but drop data traffic.

Mitigation: Forwarding is done at firmware level and users have no access to it. The host cannot modify forwarded traffic.

A node cannot be permanently configured to respond to drop all data traffic while still responding to RREQs. But a node that constantly clears it forwarding table would behave normally during route discovery but drop data traffic. So this mitigation will only hold if iwpriv msh0 fwt_reset is disabled.

Attacks on Flow of Routing Traffic

Modifying the metric in route requests/route replies.

This is perfectly possible using the iwpriv fwt_* interface into the forwarding table.

Mitigation: Disable iwpriv fwt_* commands before release?

Changes to the forwarding table via the iwpriv fwt_* interface will not affect the metric of transmitted route requests/route replies. So the mitigation is:

Mitigation: Firmware does not allow changing the advertised cost for routes (only changes that affect locally originated traffic are allowed).

Invalidating the route table in other nodes by advertising incorrect paths.

Same as previous. Furthermore, the mesh does not support proxy route replies, so intermediate nodes cannot advertise forged routes on behalf of the destination node.

Refusing to participate in the route discovery process.

Mitigation: A mesh point cannot leech the mesh: in order to send and receive traffic it must also propagate data and route management frames for other nodes.

Generate false route error messages

Route error messages propagate information about invalid routes. False route error messages could cause the deletion of valid routes, which would have to be rediscovered.

Mitigation: Route error messages are generated by the firmware and cannot be forged from the host.

Mesh Security - Access Control

The current mesh implementation only provides an Open Access control policy, where all the mesh nodes will accept and forward traffic on behalf of any other node. Open Access is particularly useful in mesh routing, as the value of the mesh generally increases with the number of users.

But there may be situations where some form of access control is useful, for instance when there is a high density of users in a small area. In that situation it may be better to only allow access to a smaller subset of authenticated users.

Access Control Policies

Based on these considerations, these are the three possible access control policies that we envision:

Open access

In open access any mesh node is allowed to participate in node discovery. This allows greater connectivity between mesh nodes. However this model requires a stronger immunity against service disruptions (see this section)

Authenticated Access only

Mesh nodes involved in forwarding should be authenticated with a common shared secret. This ensures that rogue MPs can’t subvert mesh discovery. However it reduces the connectivity of the mesh as other MPs not part of the same group cannot be part of the mesh.

Multiple Authenticated access

In this scenario mesh nodes can have multiple shared secrets. Therefore each mesh node can, based on the mesh ID or other information, use a different shared secret to join the mesh. The MP can be part of multiple mesh networks and can forward packets from one mesh to the other. This model follows the "friend of my friend is my friend" model.

Mesh Security - Confidentiality

If you have an opinion on this, please use the Discussion page

Bibliography

[1] "Techniques for Intrusion-Resistant Ad Hoc Routing Algorithms (TIARA)", Ramanujan R. et al., MILCOM 2000. 21st Century Military Communications Conference Proceedings, 2000

[2] "Intrusion Detection in Wireless Ad-Hoc Networks", Mishra A., Nadkarni K. and Patcha A. IEEE Wireless Communications, February 2004