Threema-Sicherheit

Stelle deine Frage öffentlich an die Threema-Forum-Community - über 4.800 Mitglieder helfen dir weiter. > Frage stellen <
    Zitat von Crixus


    Interessanter Bericht bzgl. der Sicherheit von Gruppenchats in Signal, WhatsApp und Threema:
    https://web-in-security.blogspot.de/2017/07/insecu…ignals-and.html
    https://eprint.iacr.org/2017/713.pdf

    Interessant sind vor allem die Reaktionen:

    "As described earlier, Threema updated their application in response to our responsible disclosure. Consequently No Duplication, No Creation, and Closeness are not attackable anymore." (Die Korrektur ist in Version 3.14 bereits drin).

    "Moxie Marlinspike responded that Signal is working on an entirely new group mechanism that we should be deploying soon"

    "WhatsApp did not hold out the prospect of fixing the described vulnerabilities."

    Einmal editiert, zuletzt von Claus (28. Juli 2017 um 15:52)


    Schade nur, dass Threema die Nutzer nicht informiert hat, weder über die Lücken, noch über deren fixes im 3.14 Update (zumindest ein "sicherheitsrelevante Fehlerbehebungen" anstatt nur "diverse Fehlerbehebungen" im Changelog wären "nett" gewesen)

    EDIT: Es steht eh im Changelog, habe ich übersehen, mein Fehler

    Einmal editiert, zuletzt von simmac (3. August 2017 um 14:52)

    Habe ein paar Fragen, die mir evtl. der ein oder andere hier beantworten kann:

    • So wie ich das Whitepaper gelesen habe, bieten Threema-Anrufe auch auf der Ebene der Ende-zu-Ende-Verschlüsselung Forward Secrecy. Liege ich hier richtig?
    • SRTP hat die Schwachstelle, dass „nur“ die Nutzdaten, nicht aber die Header-Informationen, verschlüsselt werden (Link). Wurden hier seitens Threema Anpassungen vorgenommen, siehe u. a. hier: https://tools.ietf.org/html/rfc6904

      Zitat

      SRTP only encrypts the payload of RTP packets, providing no encryption for the header. However, the header contains a variety of information which may be desirable to keep secret.One such piece of information included in the RTP header is the audio-levels of the contained media data. Effectively, anyone who can see the SRTP packets can tell whether a user is speaking or not at any given time. Although the contents of the media itself remains secret to any eavesdropper, this is still a scary prospect. For example, Law enforcement officials could determine whether a user is communicating with a known bad guy.

      Quelle: webrtc-security.github.io/

    • SRTP verwendet SRTP_AES128_CM_SHA1_32. Warum SHA1? Sollte man das mittelfristig nicht vermeiden?
    • Welche WebRTC-Library nutzt Threema in der Android- und iOS-App?

    Einmal editiert, zuletzt von Crixus (14. September 2017 um 19:55)

    1. Ja, der SRTP-Key wird über eine Diffie-Hellman Cipher Suite generiert.
    2. Unwahrscheinlich. Ob Mute evtl. einfach nur Rauschen produziert, weiß ich nicht. dbrgn?
    3. Gute Frage. Vermutlich wird in libjingle RFC 7714 (noch) nicht unterstützt.
    4. libjingle (Googles Library, siehe webrtc.org).

    Software Engineer bei Threema, hier als Individuum.

    Zitat von lgrahl


    2. Unwahrscheinlich. Ob Mute evtl. einfach nur Rauschen produziert, weiß ich nicht. dbrgn?

    Wir haben keine Anpassungen an SRTP vorgenommen. Mute wird nicht speziell behandelt, aber die Information ob ein Gerät gemuted ist oder nicht, ist ziemlich irrelevant :)

    Zitat von Crixus


    SRTP verwendet SRTP_AES128_CM_SHA1_32. Warum SHA1? Sollte man das mittelfristig nicht vermeiden?

    Mittelfristig, ja. Zukünftige Versionen der WebRTC Implementierung werden da schönere Ciphersuites unterstützen (wie z.B: AES GCM). Die Ciphersuite wird jeweils ausgehandelt, Fallback auf kaputte (z.B. 3DES) oder fehlende Verschlüsselung ist per Standard nicht erlaubt / möglich. SRTP_AES128_CM_SHA1_32 ist jedoch absolut ausreichend.

    Einmal editiert, zuletzt von dbrgn (19. September 2017 um 23:36)