6 ms·

For the English readers without Dutch sources, here is some additional information which might or might not be in the article: Police seized and operated a ser

For the English readers without Dutch sources, here is some additional information which might or might not be in the article: Police seized and operated a server of a company called Blackbox Security which offered 'crypto phones'. Basically phones pre-installed with some software sometimes with all ability to communicate disabled aside from that application. The price for these phones was 1500 EUR including a 6 month plan, afterwards 750 EUR per 6 months for usage. While the Dutch DA and Police have not given any details as to how the security was broken there are some clues (this is speculative as fuck): * A users guide that used to be published on the Blackbox Security website hints towards their chat application being XMPP+OTR. * Real-time access but no historical access hints towards an MITM to change the previously exchanged OTR keys (a common way to 'break' into a conversation). * The application seemed to not enforce and/or check the key signatures for changes. This is not the first time the Dutch DA and Police have taken action against a 'crypto phone' provider. Ennetcom, another provider was taken down a year or so ago: https://www.zdnet.com/article/police-hack-pgp-server-with-3-6-million-messages-from-organized-crime-blackberrys/ https://www.zdnet.com/article/police-hack-pgp-server-with-3-... leading to arrests as well. The reason given by the DA for the publication of this news is that threats of violence and reprisal were being made on the taken down chat messages by owners of these devices after police action was taken against them. They wrongfully blamed the people they were communicating with of leaking the information. As tensions increased retribution hits were likely and the risk to the public would be there. Hence: release the information. To re-iterate, there is so far no reason to believe the actual cryptographic protocols in use got broken but that yes; taking over the server allowed them to MITM the OTR key exchanges and/or pretend to be another client. I could get more technical but since this is all speculation I don't see much value to it.

cm2187 8y ago
To be honest if you own the server, you can push an update to the app to start sending data in clear and the user would be no wiser.
baybal2 8y ago
>* The application seemed to not enforce and/or check the key signatures for changes. Xabber clone? If so, this, again, demonstrates that automatic key renegotiaton is a glaring security vulnerability open for real world exploitation. Throw that into Moxie Marlinspike's garden. Edit, seems their app store is still up. Checkout it out yourself http://www.appstoreprivacy.com http://www.appstoreprivacy.com
lmilcin 8y ago
I have been designing cryptographic protocols for securing card payment transactions, card data and pins. I then was going with those systems through stringent certifications from various organizations, especially PCI. Not enforcing signatures when exchanging keys? Is this crypto-kindergarten? With a well designed payment system it is expected that the attackers have access to basically all of infrastructure -- servers, databases holding keys, network, disassemble terminals, bribe employees, etc. and still have no chance injecting their own keys, read pins or get any cryptographic material of value. Why can't you just guys who pretend to build secure system spend some times reading real requirements from PCI or Visa or Mastercard to get at least some idea how real secure systems are built in at least one area?
- schoen 8y ago
  I suppose that in the payment systems, there's a trusted party that has the ability to compromise transactions. The different parties in the system trust that party and rely on audit and potentially arbitration or litigation to resolve disputes about individual transactions or classes of transactions. For end-to-end encryption for messaging applications, there may not be any such entity that everyone can trust. In that case, there needs to be a solution for key exchange to allow new parties and devices to join the system. In payments you could presumably say "the banks/banking association/cryptographic contractor of the banking association is the authority that certifies new entities that join the system". In messaging you probably can't do that if you're concerned that law enforcement will force that entity to add false certifications! In other words, I think you're referring to a cryptographic problem with a somewhat different threat model.
  - lmilcin 8y ago
    There don't and should not be any trusted parties. Every trusted party is, by definition, a point of failure if the party is compromised. PCI requires that organizations control cryptographic material using rules of dual control and split knowledge. No individual should have access to entire cryptographic key and any processes and devices should require at least two people to operate. For example, HSM-s are ALWAYS operated by at least two security officers. Cryptographic keys are generated by HSM in the form of multiple components onto multiple smartcards. Each smartcard is stored in a separate safe where only the security officer/s assigned to that component have access. The HSM to be injected with keys must be operated by multiple security officers with their components. The HSM is regularly inspected -- each security officer brings his key from his safe, two keys are required to open the enclosure where the HSM is located. When the payment terminal is injected with keys there are two operators present monitoring each other to prevent tampering with the process. Etc. With good understanding of the concepts it is possible to build secure system. It's not that hard.
colanderman 8y ago
Please don't use code indent blocks for bulleted lists. They're absolutely unreadable on mobile. Reformatted: * A users guide that used to be published on the Blackbox Security website hints towards their chat application being XMPP+OTR. * Real-time access but no historical access hints towards an MITM to change the previously exchanged OTR keys (a common way to 'break' into a conversation). * The application seemed to not enforce and/or check the key signatures for changes.
- erikpukinskis 8y ago
  They wrap on iPhone
  - jiveturkey 8y ago
    not on mine
  - gronne 8y ago
    No they dont. Are you using safari?
    - TimTheTinker 8y ago
      All web browsers on iOS use the Safari (or more accurately, WebKit) rendering engine.
      - gronne 8y ago
        I know. however I imagine that some of the other “browsers” messes a bit with settings and/or rendering.
bwblabs 8y ago
I've looking into this issue for the last 2 days: The APK we all looked into is IronChat-3.40-release.apk [1], after decompiling I think it is a copy/fork of Conversations version 1.14.6 with a few more commits until October 13th 2016 [2] with Secret Space Encryptor version 1.7.2c [3]. About unencrypted support: "supportUnencrypted() { return false; }" is in the config, so probably not [4]. There is a theory (I kind of started [5]) that it might be MitM because of bad UX. This is because they used OTR without TOFU which was only added in Conversations 1.15, after the fork [6]. [1] https://ironphonestore.com/IronChat-3.40-release.apk https://ironphonestore.com/IronChat-3.40-release.apk [2] https://github.com/siacs/Conversations/tree/6371d2b7a9a2b5d7c14c998f63d7e2de6a1467d9 https://github.com/siacs/Conversations/tree/6371d2b7a9a2b5d7... [3] https://paranoiaworks.mobi/sse/ https://paranoiaworks.mobi/sse/ [4] https://twitter.com/BWBroersma/status/1060136620383453195 https://twitter.com/BWBroersma/status/1060136620383453195 [5] https://twitter.com/BWBroersma/status/1059851925234036739 https://twitter.com/BWBroersma/status/1059851925234036739 / https://twitter.com/Schellevis/status/1059852605801852929 https://twitter.com/Schellevis/status/1059852605801852929 (= the author of the article quoted by ars: https://nos.nl/l/2258309 https://nos.nl/l/2258309 ) [6] https://twitter.com/BWBroersma/status/1060278116315262976 https://twitter.com/BWBroersma/status/1060278116315262976
gammateam 8y ago
Pretending to be another client seems most likely

cm2187 8y ago

To be honest if you own the server, you can push an update to the app to start sending data in clear and the user would be no wiser.

baybal2 8y ago

>* The application seemed to not enforce and/or check the key signatures for changes. Xabber clone? If so, this, again, demonstrates that automatic key renegotiaton is a glaring security vulnerability open for real world exploitation. Throw that into Moxie Marlinspike's garden. Edit, seems their app store is still up. Checkout it out yourself http://www.appstoreprivacy.com http://www.appstoreprivacy.com

lmilcin 8y ago

I have been designing cryptographic protocols for securing card payment transactions, card data and pins. I then was going with those systems through stringent certifications from various organizations, especially PCI. Not enforcing signatures when exchanging keys? Is this crypto-kindergarten? With a well designed payment system it is expected that the attackers have access to basically all of infrastructure -- servers, databases holding keys, network, disassemble terminals, bribe employees, etc. and still have no chance injecting their own keys, read pins or get any cryptographic material of value. Why can't you just guys who pretend to build secure system spend some times reading real requirements from PCI or Visa or Mastercard to get at least some idea how real secure systems are built in at least one area?

schoen 8y ago
I suppose that in the payment systems, there's a trusted party that has the ability to compromise transactions. The different parties in the system trust that party and rely on audit and potentially arbitration or litigation to resolve disputes about individual transactions or classes of transactions. For end-to-end encryption for messaging applications, there may not be any such entity that everyone can trust. In that case, there needs to be a solution for key exchange to allow new parties and devices to join the system. In payments you could presumably say "the banks/banking association/cryptographic contractor of the banking association is the authority that certifies new entities that join the system". In messaging you probably can't do that if you're concerned that law enforcement will force that entity to add false certifications! In other words, I think you're referring to a cryptographic problem with a somewhat different threat model.
- lmilcin 8y ago
  There don't and should not be any trusted parties. Every trusted party is, by definition, a point of failure if the party is compromised. PCI requires that organizations control cryptographic material using rules of dual control and split knowledge. No individual should have access to entire cryptographic key and any processes and devices should require at least two people to operate. For example, HSM-s are ALWAYS operated by at least two security officers. Cryptographic keys are generated by HSM in the form of multiple components onto multiple smartcards. Each smartcard is stored in a separate safe where only the security officer/s assigned to that component have access. The HSM to be injected with keys must be operated by multiple security officers with their components. The HSM is regularly inspected -- each security officer brings his key from his safe, two keys are required to open the enclosure where the HSM is located. When the payment terminal is injected with keys there are two operators present monitoring each other to prevent tampering with the process. Etc. With good understanding of the concepts it is possible to build secure system. It's not that hard.

colanderman 8y ago

Please don't use code indent blocks for bulleted lists. They're absolutely unreadable on mobile. Reformatted: * A users guide that used to be published on the Blackbox Security website hints towards their chat application being XMPP+OTR. * Real-time access but no historical access hints towards an MITM to change the previously exchanged OTR keys (a common way to 'break' into a conversation). * The application seemed to not enforce and/or check the key signatures for changes.

erikpukinskis 8y ago
They wrap on iPhone
- jiveturkey 8y ago
  not on mine
- gronne 8y ago
  No they dont. Are you using safari?
  - TimTheTinker 8y ago
    All web browsers on iOS use the Safari (or more accurately, WebKit) rendering engine.
    - gronne 8y ago
      I know. however I imagine that some of the other “browsers” messes a bit with settings and/or rendering.

bwblabs 8y ago

I've looking into this issue for the last 2 days: The APK we all looked into is IronChat-3.40-release.apk [1], after decompiling I think it is a copy/fork of Conversations version 1.14.6 with a few more commits until October 13th 2016 [2] with Secret Space Encryptor version 1.7.2c [3]. About unencrypted support: "supportUnencrypted() { return false; }" is in the config, so probably not [4]. There is a theory (I kind of started [5]) that it might be MitM because of bad UX. This is because they used OTR without TOFU which was only added in Conversations 1.15, after the fork [6]. [1] https://ironphonestore.com/IronChat-3.40-release.apk https://ironphonestore.com/IronChat-3.40-release.apk [2] https://github.com/siacs/Conversations/tree/6371d2b7a9a2b5d7c14c998f63d7e2de6a1467d9 https://github.com/siacs/Conversations/tree/6371d2b7a9a2b5d7... [3] https://paranoiaworks.mobi/sse/ https://paranoiaworks.mobi/sse/ [4] https://twitter.com/BWBroersma/status/1060136620383453195 https://twitter.com/BWBroersma/status/1060136620383453195 [5] https://twitter.com/BWBroersma/status/1059851925234036739 https://twitter.com/BWBroersma/status/1059851925234036739 / https://twitter.com/Schellevis/status/1059852605801852929 https://twitter.com/Schellevis/status/1059852605801852929 (= the author of the article quoted by ars: https://nos.nl/l/2258309 https://nos.nl/l/2258309 ) [6] https://twitter.com/BWBroersma/status/1060278116315262976 https://twitter.com/BWBroersma/status/1060278116315262976

gammateam 8y ago

Pretending to be another client seems most likely