Karp, Alan H | 23 Feb 20:22 2012
Picon

A new approach to wireless security

I just attended a talk titled "Cutting Across Layers: A New Approach to Wireless Interference and
Security" by Shyamnath Gollakota of MIT that shows how to use wireless interference to both improve
throughput and security.  On the security front, he showed two examples.  First, he showed how to protect
data sent from an unmodified medical implant from eavesdroppers.  The idea is for the patient to wear a
reader that can send the data to the doctor over 3G.  The reader transmits a random signal, which the reader
can subtract out but the eavesdropper cannot.  Second, he showed how to use interference to detect a
man-in-the-middle attack during device pairing.  The approach is too complicated (and I don't
understand it well enough) for me to describe here.

The last item may be useful on wired networks.  I've long said that you don't need any crypto to know who you're
talking to as long as you know who is at the end of a particular wire.  MarkM correctly pointed out that is true
only if you have guards making sure the wire isn't tapped.  It appears that the pairing protocol described
in the talk can allow a key exchange that can detect tampering, doing away with the need for the guards as
long as you can tolerate denial of service attacks.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp
Mark Miller | 23 Feb 21:40 2012
Picon

Re: A new approach to wireless security



On Thu, Feb 23, 2012 at 11:22 AM, Karp, Alan H <alan.karp <at> hp.com> wrote:
I just attended a talk titled "Cutting Across Layers: A New Approach to Wireless Interference and Security" by Shyamnath Gollakota of MIT that shows how to use wireless interference to both improve throughput and security.  On the security front, he showed two examples.  First, he showed how to protect data sent from an unmodified medical implant from eavesdroppers.  The idea is for the patient to wear a reader that can send the data to the doctor over 3G.  The reader transmits a random signal, which the reader can subtract out but the eavesdropper cannot.  Second, he showed how to use interference to detect a man-in-the-middle attack during device pairing.  The approach is too complicated (and I don't understand it well enough) for me to describe here.

The last item may be useful on wired networks.  I've long said that you don't need any crypto to know who you're talking to as long as you know who is at the end of a particular wire.  MarkM correctly pointed out that is true only if you have guards making sure the wire isn't tapped.  It appears that the pairing protocol described in the talk can allow a key exchange that can detect tampering, doing away with the need for the guards as long as you can tolerate denial of service attacks.

This seems unlikely to me. Is there a link where we can read more?


 

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp



_______________________________________________
cap-talk mailing list
cap-talk-r2jiIPW7MOYEUp5O9OQuKg@public.gmane.org
http://www.eros-os.org/mailman/listinfo/cap-talk



--
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Karp, Alan H | 23 Feb 23:42 2012
Picon

Re: A new approach to wireless security

MarkM asked if there was a link for reading more.  He’s in a better position to google for it than I am.

 

________________________

Alan Karp

Principal Scientist

Virus Safe Computing Initiative

Hewlett-Packard Laboratories

1501 Page Mill Road

Palo Alto, CA 94304

(650) 857-3967, fax (650) 857-7029

http://www.hpl.hp.com/personal/Alan_Karp

 

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Mark Miller | 24 Feb 00:03 2012
Picon

Re: A new approach to wireless security

The top hit was <http://comments.gmane.org/gmane.comp.capabilities.general/13648> ;).


Is <http://people.csail.mit.edu/gshyam/Papers/IMDShield.pdf> it?

On Thu, Feb 23, 2012 at 11:22 AM, Karp, Alan H <alan.karp <at> hp.com> wrote:
I just attended a talk titled "Cutting Across Layers: A New Approach to Wireless Interference and Security" by Shyamnath Gollakota of MIT that shows how to use wireless interference to both improve throughput and security.  On the security front, he showed two examples.  First, he showed how to protect data sent from an unmodified medical implant from eavesdroppers.  The idea is for the patient to wear a reader that can send the data to the doctor over 3G.  The reader transmits a random signal, which the reader can subtract out but the eavesdropper cannot.  Second, he showed how to use interference to detect a man-in-the-middle attack during device pairing.  The approach is too complicated (and I don't understand it well enough) for me to describe here.

The last item may be useful on wired networks.  I've long said that you don't need any crypto to know who you're talking to as long as you know who is at the end of a particular wire.  MarkM correctly pointed out that is true only if you have guards making sure the wire isn't tapped.  It appears that the pairing protocol described in the talk can allow a key exchange that can detect tampering, doing away with the need for the guards as long as you can tolerate denial of service attacks.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp



_______________________________________________
cap-talk mailing list
cap-talk-r2jiIPW7MOYEUp5O9OQuKg@public.gmane.org
http://www.eros-os.org/mailman/listinfo/cap-talk



--
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Karp, Alan H | 24 Feb 00:07 2012
Picon

Re: A new approach to wireless security

That’s the medical device paper.  The pairing paper, the one I think is relevant to the wire, is http://people.csail.mit.edu/gshyam/Papers/TEP.pdf.

 

________________________

Alan Karp

Principal Scientist

Virus Safe Computing Initiative

Hewlett-Packard Laboratories

1501 Page Mill Road

Palo Alto, CA 94304

(650) 857-3967, fax (650) 857-7029

http://www.hpl.hp.com/personal/Alan_Karp

 

From: cap-talk-bounces-r2jiIPW7MOYEUp5O9OQuKg@public.gmane.org [mailto:cap-talk-bounces-r2jiIPW7MOYEUp5O9OQuKg@public.gmane.org] On Behalf Of Mark Miller
Sent: Thursday, February 23, 2012 3:04 PM
To: General discussions concerning capability systems.
Subject: Re: [cap-talk] A new approach to wireless security

 

The top hit was <http://comments.gmane.org/gmane.comp.capabilities.general/13648> ;).

 

Is <http://people.csail.mit.edu/gshyam/Papers/IMDShield.pdf> it?

On Thu, Feb 23, 2012 at 11:22 AM, Karp, Alan H <alan.karp-VXdhtT5mjnY@public.gmane.org> wrote:

I just attended a talk titled "Cutting Across Layers: A New Approach to Wireless Interference and Security" by Shyamnath Gollakota of MIT that shows how to use wireless interference to both improve throughput and security.  On the security front, he showed two examples.  First, he showed how to protect data sent from an unmodified medical implant from eavesdroppers.  The idea is for the patient to wear a reader that can send the data to the doctor over 3G.  The reader transmits a random signal, which the reader can subtract out but the eavesdropper cannot.  Second, he showed how to use interference to detect a man-in-the-middle attack during device pairing.  The approach is too complicated (and I don't understand it well enough) for me to describe here.

The last item may be useful on wired networks.  I've long said that you don't need any crypto to know who you're talking to as long as you know who is at the end of a particular wire.  MarkM correctly pointed out that is true only if you have guards making sure the wire isn't tapped.  It appears that the pairing protocol described in the talk can allow a key exchange that can detect tampering, doing away with the need for the guards as long as you can tolerate denial of service attacks.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp



_______________________________________________
cap-talk mailing list
cap-talk-r2jiIPW7MOYEUp5O9OQuKg@public.gmane.org
http://www.eros-os.org/mailman/listinfo/cap-talk



 

--
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Mark Miller | 24 Feb 03:12 2012
Picon

Fwd: [nodejs] Capability security for Web apps: request for comment.

This started a promising thread at <https://groups.google.com/forum/?hl=en?hl%3Den&fromgroups#!topic/nodejs/VlLUui1feyA>, but std misconceptions have already been raised and I don't have the time to answer. Can someone please engage with this? This is an important community to convince, and no opposing ideas have yet become entrenched. Thanks.



---------- Forwarded message ----------
From: Dan Yoder <dan-xUIWBoI7KZ0@public.gmane.org>
Date: Tue, Feb 21, 2012 at 7:28 PM
Subject: [nodejs] Capability security for Web apps: request for comment.
To: nodejs <nodejs <at> googlegroups.com>


Our Web API uses a form of capability security. It's still evolving,
but I've written about what we've done thus far here:

http://www.spire.io/posts/web-capabilities.html

We'd love to hear from the Node community as to what they think of
this approach.

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
nodejs+unsubscribe <at> googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en



--
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Rob Meijer | 24 Feb 09:36 2012
Picon
Picon

Re: Fwd: [nodejs] Capability security for Web apps: request for comment.

Ouch, didn't know these were moderated. Depending on the way it is, this
discussion might be in for a captalk flood ;-)

On Fri, February 24, 2012 03:12, Mark Miller wrote:
> This started a promising thread at <
> https://groups.google.com/forum/?hl=en?hl%3Den&fromgroups#!topic/nodejs/VlLUui1feyA>,
> but std misconceptions have already been raised and I don't have the time
> to answer. Can someone please engage with this? This is an important
> community to convince, and no opposing ideas have yet become entrenched.
> Thanks.
>
>
> ---------- Forwarded message ----------
> From: Dan Yoder <dan@...>
> Date: Tue, Feb 21, 2012 at 7:28 PM
> Subject: [nodejs] Capability security for Web apps: request for comment.
> To: nodejs <nodejs@...>
>
>
> Our Web API uses a form of capability security. It's still evolving,
> but I've written about what we've done thus far here:
>
> http://www.spire.io/posts/web-capabilities.html
>
> We'd love to hear from the Node community as to what they think of
> this approach.
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@...
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@...
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
>
> --
> Text by me above is hereby placed in the public domain
>
>   Cheers,
>   --MarkM
> _______________________________________________
> cap-talk mailing list
> cap-talk@...
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
Rob Meijer | 25 Feb 16:08 2012
Picon
Picon

3 step hashing for decomposition: feedback needed.

A while ago I made a design for a database free version of the
sparse-capability part of the upcoming MinorFs2. MinorFs2 is meant as a
retrofitting suitable replacement for the old MinorFs that basically
demanded a good fit of the 'pseudo persistent process' concept that
arguably for most existing is a bad fit.

Although I asked a few people with more cartographic knowledge than me for
a review in the past, until now I haven't had any feedback from people
with a sufficiently solid background to be able to spot cryptographic
weaknesses in my design.

The base idea is that we have a loop-back file-system where the top
file-system directory is accessible (read/write) with a randomly generated
sparse key (key1). The file-system has a private salt that it uses to
derive other keys with. In order to , for a node, derive a read-only key
(key2) from a read/write key (key1) we say that:

key2 = sha256(key1,salt)

Now comes the scary part, in order to derive a sparse capability key for a
sub directory or file within a given directory, lets call this sub node
node', I use :

key1' = sha256(name',key2,salt)

In my file-system I won't expose key1' to the holder of key2, only the
holder of key1 is allowed to extract key1' from the file-system, and the
security of this design thus depends on the file-system being able to keep
its salt secret.

In my design I let key2 double as the encryption/decryption key for the
file in the underlying file-system. Than in order to locate the
representation of the node in the underlying file-system, I use a third
hash to determine the relative storage location in the underlying
file-system:

key3 = sha256(key2,salt)

So basically anyone with read access to the underlying file-system (in
case of failure of the systems access control) should be unable to extract
either the file-system structure or any data without access to a valid
sparse key.

I've put a graphical representation on the wiki:
http://minorfs.polacanthus.net/wiki/Minorfs2_cap_fs

I would really appreciate if someone more into cryptography than me could
either confirm that this design does not have a cryptographic weakness or
if it does, help me to address it.
David Barbour | 25 Feb 19:18 2012
Picon

Re: 3 step hashing for decomposition: feedback needed.

I have a few thoughts on the subject. I've sketched out a similar design in the past, for distributed state:


First, use HMAC instead of the raw hash. The HMAC will provide a lot of extra protection when SHA256 is eventually (and inevitably) compromised.

Second, get rid of the private salt. Authority is provided by the keys, right? I think the salt is just obfuscating analysis. Where you use the salt currently, you could use some artificial directory names of the form "#ReadOnly" or "#Location".

So you'll end up with:
   key2 = HMAC(SHA256,key1,"#ReadOnly")
   key3 = HMAC(SHA256,key2,"#Location")

Anyhow, I do see a potential problem with the direction you're considering. Whether you use private salts or my suggestion, you'll have a set of sparse keys generated from human-meaningful `paths`:

   key1 = /foo/bar
   key2 = /foo/bar#ReadOnly
   key3 = /foo/bar#ReadOnly#Location

But some of these paths will be redundant in meaning.
   key2 = /foo/bar#ReadOnly
   key2alt = /foo#ReadOnly/bar

But you cannot generate key2alt from key1. This would not be a problem if you weren't doubling the read-only key for encryption/decryption. But I think this would mean you need to provide key2alt alongside key1. And if you're going to provide multiple keys anyway, you might as well favor split capabilities. That is:

  key1 = (key1Read,key1Write).

In many cases we'd want to split these anyway, e.g. the writer to a channel is not generally authorized to read from it.

Regards,

Dave

On Sat, Feb 25, 2012 at 7:08 AM, Rob Meijer <capibara-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> wrote:
A while ago I made a design for a database free version of the
sparse-capability part of the upcoming MinorFs2. MinorFs2 is meant as a
retrofitting suitable replacement for the old MinorFs that basically
demanded a good fit of the 'pseudo persistent process' concept that
arguably for most existing is a bad fit.

Although I asked a few people with more cartographic knowledge than me for
a review in the past, until now I haven't had any feedback from people
with a sufficiently solid background to be able to spot cryptographic
weaknesses in my design.

The base idea is that we have a loop-back file-system where the top
file-system directory is accessible (read/write) with a randomly generated
sparse key (key1). The file-system has a private salt that it uses to
derive other keys with. In order to , for a node, derive a read-only key
(key2) from a read/write key (key1) we say that:

key2 = sha256(key1,salt)

Now comes the scary part, in order to derive a sparse capability key for a
sub directory or file within a given directory, lets call this sub node
node', I use :

key1' = sha256(name',key2,salt)

In my file-system I won't expose key1' to the holder of key2, only the
holder of key1 is allowed to extract key1' from the file-system, and the
security of this design thus depends on the file-system being able to keep
its salt secret.

In my design I let key2 double as the encryption/decryption key for the
file in the underlying file-system. Than in order to locate the
representation of the node in the underlying file-system, I use a third
hash to determine the relative storage location in the underlying
file-system:

key3 = sha256(key2,salt)

So basically anyone with read access to the underlying file-system (in
case of failure of the systems access control) should be unable to extract
either the file-system structure or any data without access to a valid
sparse key.


I've put a graphical representation on the wiki:
http://minorfs.polacanthus.net/wiki/Minorfs2_cap_fs

I would really appreciate if someone more into cryptography than me could
either confirm that this design does not have a cryptographic weakness or
if it does, help me to address it.



_______________________________________________
cap-talk mailing list
cap-talk-r2jiIPW7MOYEUp5O9OQuKg@public.gmane.org
http://www.eros-os.org/mailman/listinfo/cap-talk

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Rob Meijer | 26 Feb 13:19 2012
Picon
Picon

Re: 3 step hashing for decomposition: feedback needed.

On Sat, February 25, 2012 19:18, David Barbour wrote:
> I have a few thoughts on the subject. I've sketched out a similar design
> in
> the past, for distributed state:
>
> First, use HMAC instead of the raw hash. The HMAC will provide a lot of
> extra protection when SHA256 is eventually (and inevitably) compromised.

Sounds like a good idea, so this is basically chaining two hashing
algoritms in case one gets compromised?

> Second, get rid of the private salt. Authority is provided by the keys,
> right? I think the salt is just obfuscating analysis. Where you use the
> salt currently, you could use some artificial directory names of the
> form "#ReadOnly" or "#Location".
>
> So you'll end up with:
>    key2 = HMAC(SHA256,key1,"#ReadOnly")
>    key3 = HMAC(SHA256,key2,"#Location")

Yes, so I should use the secret salt only for getting key1' ?:

   key1' = HMAC(SHA256,key2,name')

I'll need the secret salt there to prevent the holder of key2 to be able
to get at key1'. That is, the holder of key1 has the authority to derive
key2, key1' and key2' but the holder of key2 should only have the
authority to derive key2'.

> Anyhow, I do see a potential problem with the direction you're
> considering.
> Whether you use private salts or my suggestion, you'll have a set of
> sparse
> keys generated from human-meaningful `paths`:
>
>    key1 = /foo/bar
>    key2 = /foo/bar#ReadOnly
>    key3 = /foo/bar#ReadOnly#Location
>
> But some of these paths will be redundant in meaning.
>    key2 = /foo/bar#ReadOnly
>    key2alt = /foo#ReadOnly/bar
>
> But you cannot generate key2alt from key1. This would not be a problem if
> you weren't doubling the read-only key for encryption/decryption.

Basically if we take:

     key1 = /foo
     key2 = /foo#ReadOnly

Than for sub node 'bar':

     key1' = /foo/bar
     key2' = /foo/bar/#ReadOnly

Since in my design key1' is derived from key2, both /foo/bar#ReadOnly and
/foo#ReadOnly/bar will resolve to the same.

> But I
> think this would mean you need to provide key2alt alongside key1. And if
> you're going to provide multiple keys anyway, you might as well favor
> split
> capabilities. That is:
>
>   key1 = (key1Read,key1Write).
>
> In many cases we'd want to split these anyway, e.g. the writer to a
> channel
> is not generally authorized to read from it.

In the old MinorFs1, all files and directories were read/write. Providing
read-only as an attenuation pattern made a lot of sense. I really didn't
think of also considering write only as an attenuation for files and
directories. I would have to consider if there are any non contrived
use-cases for write-only attenuation.

> Regards,
>
> Dave
>
> On Sat, Feb 25, 2012 at 7:08 AM, Rob Meijer <capibara@...> wrote:
>
>> A while ago I made a design for a database free version of the
>> sparse-capability part of the upcoming MinorFs2. MinorFs2 is meant as a
>> retrofitting suitable replacement for the old MinorFs that basically
>> demanded a good fit of the 'pseudo persistent process' concept that
>> arguably for most existing is a bad fit.
>>
>> Although I asked a few people with more cartographic knowledge than me
>> for
>> a review in the past, until now I haven't had any feedback from people
>> with a sufficiently solid background to be able to spot cryptographic
>> weaknesses in my design.
>>
>> The base idea is that we have a loop-back file-system where the top
>> file-system directory is accessible (read/write) with a randomly
>> generated
>> sparse key (key1). The file-system has a private salt that it uses to
>> derive other keys with. In order to , for a node, derive a read-only key
>> (key2) from a read/write key (key1) we say that:
>>
>> key2 = sha256(key1,salt)
>>
>> Now comes the scary part, in order to derive a sparse capability key for
>> a
>> sub directory or file within a given directory, lets call this sub node
>> node', I use :
>>
>> key1' = sha256(name',key2,salt)
>>
>> In my file-system I won't expose key1' to the holder of key2, only the
>> holder of key1 is allowed to extract key1' from the file-system, and the
>> security of this design thus depends on the file-system being able to
>> keep
>> its salt secret.
>>
>> In my design I let key2 double as the encryption/decryption key for the
>> file in the underlying file-system. Than in order to locate the
>> representation of the node in the underlying file-system, I use a third
>> hash to determine the relative storage location in the underlying
>> file-system:
>>
>> key3 = sha256(key2,salt)
>>
>> So basically anyone with read access to the underlying file-system (in
>> case of failure of the systems access control) should be unable to
>> extract
>> either the file-system structure or any data without access to a valid
>> sparse key.
>>
>>
>> I've put a graphical representation on the wiki:
>> http://minorfs.polacanthus.net/wiki/Minorfs2_cap_fs
>>
>> I would really appreciate if someone more into cryptography than me
>> could
>> either confirm that this design does not have a cryptographic weakness
>> or
>> if it does, help me to address it.
>>
>>
>>
>> _______________________________________________
>> cap-talk mailing list
>> cap-talk@...
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>
> _______________________________________________
> cap-talk mailing list
> cap-talk@...
> http://www.eros-os.org/mailman/listinfo/cap-talk
>

Gmane