Mesh Security: Difference between revisions
(Refactored) |
|||
Line 1: | Line 1: | ||
{{OLPC}} |
{{OLPC}} |
||
== Mesh Security |
== Mesh Security == |
||
⚫ | |||
Mesh Security are the set of security measures taken to: |
|||
# prevent service disruption |
|||
⚫ | |||
# ensure confidentiality |
|||
Each of the security area is discussed in a subsection below. |
|||
== Mesh Security - Robustness == |
|||
=== Introduction === |
=== Introduction === |
||
This analysis focuses the risks that may prevent the mesh to prevent the mesh subsystem to performing its duty: is to transfer data between mesh points over |
|||
a partially connected mesh network. |
a partially connected mesh network. |
||
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 |
It is important to keep in mind that mesh networks, due to the lack of |
||
Line 13: | Line 24: | ||
insecure. For instance, there is no possible defense against disruptions of |
insecure. For instance, there is no possible defense against disruptions of |
||
the physical medium with jammers and similar equipment. In the analysis below |
the physical medium with jammers and similar equipment. In the analysis below |
||
we focus on the measures |
we focus on the measures that need to be adopted to prevent attacks performed |
||
⚫ | |||
that need to be adopted to prevent attacks performed by the xo's themselves, |
|||
as such attacks |
|||
⚫ | |||
The |
The current implementation of the mesh in OLPC does not provide mechanisms to |
||
⚫ | |||
the |
|||
measures may be implemented in the future and discussed in sectionTODO. Thus |
|||
⚫ | |||
this analysis does not cover mitigations to attacks on privacy or unauthorized |
|||
network access. |
network access. |
||
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 95: | Line 103: | ||
cannot be forged from the host. |
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. |
|||
⚫ | |||
--[[User:Jcardona|Jcardona]] 15:16, 2 April 2007 (EDT) |
|||
Based on these considerations, these are the three possible access control |
|||
⚫ | |||
policies that we envision: |
|||
⚫ | |||
⚫ | |||
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 |
|||
[http://wiki.laptop.org/index.php?title=Mesh_Security#Mesh_Security_-_Robustness 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 |
|||
# By flooding the network with mesh packets |
|||
cannot be part of the mesh. |
|||
⚫ | |||
=== The mesh security protocol should ensure === |
|||
In this scenario mesh nodes can have multiple shared secrets. Therefore each |
|||
# Authenticated access to the mesh |
|||
mesh node can, based on the mesh ID or other information, use a different |
|||
# Protect content through encryption |
|||
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 == |
|||
⚫ | |||
⚫ | |||
In open access any mesh node is allowed to participate in node discovery. This allows greater connectivity between mesh nodes. However intermediate rouge MPs can provide false information on Path Metric, thereby preventing proper route discovery. This is therefore not acceptable. |
|||
''If you have an opinion on this, please use the Discussion page'' |
|||
# Authenticated Access only |
|||
Mesh nodes involved in forwarding should be authenticated with a common shared secret. This ensures that rouge MPs can’t subvert mesh discovery. However it reduces the connectivity of the mesh as other MPs not part of the same group cannot assist in mesh discovery. |
|||
⚫ | |||
⚫ | |||
In this scenario mesh nodes can have multiple shared secrets. Therefore each mesh node can based on the mesh SSID or other information, use a different shared secret to join the mesh. The MP can be part of multiple mesh and can forward packets from one mesh to the other. |
|||
⚫ | |||
--[[User:rchokshi|rchokshi]] 15:43, 10 April 2007 (PDT) |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ |
Revision as of 02:24, 12 April 2007
Mesh Security
Mesh Security Goals
Mesh Security are the set of security measures taken to:
- prevent service disruption
- prevent unauthorized access the network
- ensure confidentiality
Each of the security area is discussed in a subsection below.
Mesh Security - Robustness
Introduction
This analysis focuses the risks that may prevent the mesh to prevent the mesh subsystem to performing its duty: is to transfer data between mesh points over a partially connected mesh 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 sectionTODO. 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.
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.
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?
Invalidating the route table in other nodes by advertising incorrect paths.
Same as previous.
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