[messaging] EFF Secure Messaging Scorecard

[zaki at manian.org]

My understanding is that the mechanism Apple would have to use to actively
MITM an account is the same mechanism as adding a new device to a user's
iMessage account. This produces a notification on the user's other devices
that  effectively notify when an additional public key is registered for
the user name.

Obviously this is all proprietary software but as designed, an active MITM
of iMessage messages would be visible to the recipient as an unexpected
"device added" message.
 On Nov 5, 2014 9:01 PM, "Tao Effect" <contact at taoeffect.com> wrote:

> Half-answering the first part of my question:
>
> It seems that the methodology that was used is not accurately represented
> by the 2nd column header.
>
> In other words, this:
>
> *2.* *Is your communication encrypted with a key the provider doesn't
> have access to?*
> This criterion requires that all user communications are end-to-end
> encrypted. This means the keys necessary to decrypt messages must be
> generated and stored at the endpoints (i.e. by users, not by servers). The
> keys should never leave endpoints except with explicit user action, such as
> to backup a key or synchronize keys between two devices. It is fine if
> users' public keys are exchanged using a centralized server.
>
>
> Does not equal this:
>
> *Encrypted so the provider can’t read it?*
>
>
>
> The provider can read messages if it acts as a MITM, and Apple does act as
> a MITM. Therefore Apples has the capability to read all iMessages, and does
> not provide end-to-end encryption.
>
> The second concern is regarding the plain-text storage of messages (or
> storage with a key belonging to Apple), which appears to allow Apple to
> decrypt messages stored by iCloud. This is expanded further by the Ars
> Technical article linked to in the second twitter link I mentioned
> previously.
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Nov 5, 2014, at 8:45 PM, Tao Effect <contact at taoeffect.com> wrote:
>
> I echo nikos questions, especially question #2:
>
> 2. How is Skype communications "encrypted so the provider can't read"
> verified? (or even more important how is this compatible with Prism? ;))
>
>
> Sorry if I missed it, but I searched and don't believe he received an
> answer.
>
> It seems to me this question also applies to Apple's iMessages, which can
> be read by the provider:
>
> https://twitter.com/taoeffect/status/529841963378671618
>
> Also, I don't believe Apple deserves the checkbox for "Are past comms
> secure if keys are stolen", since that does not appear to be the case:
>
> https://twitter.com/taoeffect/status/529852246125981696
>
> In summary, could someone please either provide an explanation for why
> Apple received these two checkbox, or could the EFF please update their
> table so that that Apple's iMessages is truthfully represented in the table?
>
> Thank you,
> Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Nov 4, 2014, at 10:02 AM, Nikos Roussos <comzeradd at fsfe.org> wrote:
>
> On 11/04/2014 06:43 PM, Joseph Bonneau wrote:
>
> First version launched today:
> https://www.eff.org/secure-messaging-scorecard
>
> This was a collaboration between tech advisers (primarily Peter
> Eckersley and myself) and a good team of people with experience in
> journalism and activism.
>
>
> This is indeed a great tool. Kudos for work. Some comments:
>
> 1. How is that iMessage, Facebook Chat or Hangouts are *independently*
> audited if there is no code available?
>
> 2. How is Skype communications "encrypted so the provider can't read"
> verified? (or even more important how is this compatible with Prism? ;))
>
> 3. There should be a column "Does is it require to provide your phone
> number?", which should be considered a security drawback (especially for
> journalists or their sources).
>
> 4. Probably a column for extra points if an app can easily route traffic
> through Tor (like ChatSecure).
>
> 5. Not 100% sure, but I think that pidgin/libpurple have been audited in
> the past.
>
>
> ~nikos
>
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
>
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141105/0568a2b5/attachment.html>