• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: authenticating peers
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: authenticating peers


  • Subject: Re: authenticating peers
  • From: Michael Ash <email@hidden>
  • Date: Sat, 29 May 2010 17:42:17 -0400

On Sat, May 29, 2010 at 3:04 PM, Jens Alfke <email@hidden> wrote:
> This is rapidly heading off-topic, but:
> On May 29, 2010, at 4:15 AM, Michael Ash wrote:
>
>> Man-in-the-middle: if I execute the attack the first time you talk to
>> a given peer, you have no way of detecting me.
>
> This is avoided using an out-of-band exchange of a secret over a trusted
> channel (direct line-of-sight, voice, etc.) The common “enter this 4-digit
> number on the other device” task (e.g. pairing your iPhone’s Remote app with
> iTunes) is a type of this. In my Cloudy project the secret was derived from
> a hash of the public key[1]; a MITM would have to find a hash collision in
> real time to spoof it.
>
>> Impersonation: I use a legitimate copy to talk to you once. Now we
>> have two peers which have identified themselves. Afterwards, I take my
>> copy of the app and modify it to emit malicious code.
>
> Sure this is a problem, but it’s not a problem of authentication. If I
> decide to trust you, but you’re not trustworthy, that’s a social problem not
> a technical one. Or if your device / account / key is compromised, you need
> a revocation protocol to contain the damage.
> If the point you’re making is that you can’t trust the incorruptibility of
> data even if it was received from a trusted source, then we’re in violent
> agreement :) So back to the topic of the thread: passing remote data to
> NSUnarchiver is a security hole. Don’t do it.

I think we both agree overall, but I believe your response above
misses the point. You seem to be concerned with authentication, i.e.
making sure that you're talking to who you think you're talking to.
But authentication is completely orthogonal to trust. Talking about
exchanging PINs and using certificates and such is irrelevant to the
problem at hand.

Mike
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: authenticating peers
      • From: Barry Skidmore <email@hidden>
References: 
 >isKindofClass with NSData and NSKeyUnarchiver (From: Philip Vallone <email@hidden>)
 >Re: isKindofClass with NSData and NSKeyUnarchiver (From: Ken Thomases <email@hidden>)
 >Re: isKindofClass with NSData and NSKeyUnarchiver (From: Graham Cox <email@hidden>)
 >Re: isKindofClass with NSData and NSKeyUnarchiver (From: Philip Vallone <email@hidden>)
 >Re: isKindofClass with NSData and NSKeyUnarchiver (From: Uli Kusterer <email@hidden>)
 >Re: isKindofClass with NSData and NSKeyUnarchiver (From: Jens Alfke <email@hidden>)
 >Re: isKindofClass with NSData and NSKeyUnarchiver (From: Philip Vallone <email@hidden>)
 >Re: isKindofClass with NSData and NSKeyUnarchiver (From: Michael Ash <email@hidden>)
 >Re: authenticating peers (From: Jens Alfke <email@hidden>)
 >Re: authenticating peers (From: Michael Ash <email@hidden>)
 >Re: authenticating peers (From: Jens Alfke <email@hidden>)

  • Prev by Date: Re: NSError* reference in method Re: deprecated method
  • Next by Date: Re: Help w/ first step of creating Help Book for app
  • Previous by thread: Re: authenticating peers
  • Next by thread: Re: authenticating peers
  • Index(es):
    • Date
    • Thread