1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Microsoft: Teams bekommt Ende…

Für "Teams", welche dem Programmnamen gerecht werden...

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. Für "Teams", welche dem Programmnamen gerecht werden...

    Autor: JouMxyzptlk 24.10.21 - 21:09

    ...müsste quasi eine Mini-PKI dort erstellt werden, wo die Konferenz eingerichtet wird. Also quasi Lokal auf dem Rechner. Dann geht das mit dem entschlüsseln/verschlüsseln querbeet.
    Mal sehen wann und ob es so kommt. Denn das stellt sich wieder dem Cloud-Gedanken in den Weg, welcher diese PKI eben nicht lokal haben soll. Im Prinzip auch umsetzbar, nur eine Stufe schwieriger.

    Ultra HD ist LOW RES! 8K bis 16K sind mein Metier.

  2. Re: Für "Teams", welche dem Programmnamen gerecht werden...

    Autor: Maddix 25.10.21 - 07:49

    JouMxyzptlk schrieb:
    --------------------------------------------------------------------------------
    > ...müsste quasi eine Mini-PKI dort erstellt werden, wo die Konferenz
    > eingerichtet wird. Also quasi Lokal auf dem Rechner. Dann geht das mit dem
    > entschlüsseln/verschlüsseln querbeet.
    > Mal sehen wann und ob es so kommt. Denn das stellt sich wieder dem
    > Cloud-Gedanken in den Weg, welcher diese PKI eben nicht lokal haben soll.
    > Im Prinzip auch umsetzbar, nur eine Stufe schwieriger.
    Wird eher spannend, ob man im Unternehmenskontext, wo bereits eine PKI Lösung auf allen Endgeräten im Einsatz ist, in Zukunft vielleicht diese nutzen kann. Wäre eigentlich ganz nett.

  3. Re: Für "Teams", welche dem Programmnamen gerecht werden...

    Autor: Thinal 25.10.21 - 08:14

    Für wie viele Leute in der Konferenz soll das funktionieren? Die SChlüsselerzeugung und der Austausch ist kein Problem, aber dann müsste der lokale Rechner alle eingehenden Streams entschlüsseln und seinen eigenen N mal verschlüsseln und auch N mal über die Leitung schicken. In Deutschland? Mit dem Internet? Und es hat auch nicht jeder ein High End Gerät, dass das schafft.

  4. Re: Für "Teams", welche dem Programmnamen gerecht werden...

    Autor: christian_k 25.10.21 - 09:22

    Das ist nicht so schwer. Jeder Teilnehmer hat seinen individuellen asymmetrischen private und Public Key, z.B. für RSA. Jeder hat die Public Keys der anderen.

    Man verschlüsselt den ausgehenden Stream nur 1x mit einem systemischen Algorithmus (z.B. AES). Den AES Key
    erzeugt man zufällig immer wieder neu und verschlüsselt ihn mehrmals, einzeln für jeden anderen Teilnehmer mit dessen Public Key.
    Das ganze schickt man - nur 1x- zum Server und der verteilt es an alle.
    Jeder Empfänger kann mit seinem private Key den AES Key entschlüsseln und damit wiederum Bild und Ton.

    Der Bedarf an Rechenleistung hält sich in Grenzen, weil man nicht den ganzen Stream mit einem Public Key Verfahren verschlüsseln muss, sondern nur mit AES, was wesentlich einfacher ist.
    Man muss also 1xAES verschlüsseln und (N-1)x AES entschlüsseln. Das ist heute machbar und AES oft in Hardware implementiert.
    Das rechenaufwändige RSA Verfahren muss nur auf sehr geringe Datenmengen (die AES Keys) angewendet werden.

    Der Bedarf an Bandbreite (vor allem auch an Upload) ändert sich nicht gegenüber einer nicht verschlüsselten Konferenz.



    6 mal bearbeitet, zuletzt am 25.10.21 09:30 durch christian_k.

  5. Re: Für "Teams", welche dem Programmnamen gerecht werden...

    Autor: 486dx4-160 25.10.21 - 10:58

    christian_k schrieb:
    --------------------------------------------------------------------------------
    > Das ist nicht so schwer. Jeder Teilnehmer hat seinen individuellen
    > asymmetrischen private und Public Key, z.B. für RSA. Jeder hat die Public
    > Keys der anderen.
    >
    > Man verschlüsselt den ausgehenden Stream nur 1x mit einem systemischen
    > Algorithmus (z.B. AES). Den AES Key
    > erzeugt man zufällig immer wieder neu und verschlüsselt ihn mehrmals,
    > einzeln für jeden anderen Teilnehmer mit dessen Public Key.
    > Das ganze schickt man - nur 1x- zum Server und der verteilt es an alle.
    > Jeder Empfänger kann mit seinem private Key den AES Key entschlüsseln und
    > damit wiederum Bild und Ton.
    >
    > Der Bedarf an Rechenleistung hält sich in Grenzen, weil man nicht den
    > ganzen Stream mit einem Public Key Verfahren verschlüsseln muss, sondern
    > nur mit AES, was wesentlich einfacher ist.
    > Man muss also 1xAES verschlüsseln und (N-1)x AES entschlüsseln. Das ist
    > heute machbar und AES oft in Hardware implementiert.
    > Das rechenaufwändige RSA Verfahren muss nur auf sehr geringe Datenmengen
    > (die AES Keys) angewendet werden.
    >
    > Der Bedarf an Bandbreite (vor allem auch an Upload) ändert sich nicht
    > gegenüber einer nicht verschlüsselten Konferenz.

    Das funktioniert so nicht, zumindest nicht gut:
    Stell dir vor 10 Leute mit verschieden guter Internetverbindung (Gigabit bis UMTS im Randgebiet) sind zusammen in einer Konferenz.
    Die einen senden mit 20 MBit/s, während die anderen maximal 2 Mbit/s empfangen können.
    Aktuell transkodiert der Server die einzelnen Streams runter, bei Ende-zu-Ende-Verschlüsselung geht das nicht und die zwei sehen rein gar nichts mehr.
    Natürlich könnte auch jeder Teilnehmer die verschiedene Auflösungen senden (4K, 2K, 1080, 720 520, 360, 180, was auch immer die anderen so anfordern) - was dann aber ein mehrfaches an Bandbreite und Rechenleistung kostet. Auch nicht gut.

    Ende-zu-Ende-Verschlüsselung braucht man ja nur, wenn man dem Serverbetreiber nicht vertraut. Lösung: Server selbst betreiben. Keine Ahnung ob das mit MS Teams geht, wenn einem Sicherheit wichtig ist muss man halt was anderes nehmen.

  6. Re: Für "Teams", welche dem Programmnamen gerecht werden...

    Autor: JouMxyzptlk 25.10.21 - 12:07

    Thinal schrieb:
    --------------------------------------------------------------------------------
    > Für wie viele Leute in der Konferenz soll das funktionieren? Die
    > SChlüsselerzeugung und der Austausch ist kein Problem, aber dann müsste der
    > lokale Rechner alle eingehenden Streams entschlüsseln und seinen eigenen N
    > mal verschlüsseln und auch N mal über die Leitung schicken. In Deutschland?
    > Mit dem Internet?

    Falsche Denkweise!
    Dadurch dass es eine mini-PKI gibt kann man es so machen dass alle beteiligten dein Stream entschlüsseln könnne. Auch wenn der Stream, verschlüsselt, über den Umweg bei Microsoft geht bleibt weiterhin Ende zu Ende Verschlüsselung aktiv ohne dass Microsoft reinschauen kann.
    Das einzige was gebraucht wird ist guter DOWNLOAD wenn es viele Streams werden, aber Upload ist nur dein Stream.
    Prinzipiell kann es auch in der Cloud entschlüsselt-umcodiert-verschlüsselt werden, aber das braucht wieder vertrauen wenn MS bei der Mini-PKI mit dabei sein soll.

    > Und es hat auch nicht jeder ein High End Gerät, dass das schafft.

    Braucht kein High-Tech. Dual-Core (ab Sandy Bridge) mit Hyperthreading reicht. Und wenn nicht dann muss die Firma eben was zur Verfügung stellen.

  7. Re: Für "Teams", welche dem Programmnamen gerecht werden...

    Autor: christian_k 25.10.21 - 12:14

    Wie es bei Teams ist, kann ich Ihnen nicht sagen.

    Bekannt ist es aber zB bei Jitsi, ist ja OpenSource.

    Dort werden die Streams NICHT vom Server transkodiert, auch nicht ohne Verschlüsselung. Es würde die Hardware Anforderungen des Servers massiv erhöhen (mehrere Konferenzen gleichzeitig auf einem Server mit je mehreren Streams in Echtzeit in mehrere Auflösungen umrechnen!), außerdem verlängert es unweigerlich die Latenz - und bei Videokonferenzen ist jede zusätzliche Latenz ein Problem. Der Server leitet nur weiter und jeder Empfänger bekommt das gleiche Video - Kleister gemeinsamer Nenner.

    In der Praxis hält sich das Problem in Grenzen. Normalerweise stellt man das so ein, dass jeder deutlich unter 1 MBit/s sendet, man muss ohnehin damit leben, dass up fast überall viel weniger ist als down und im Bild bewegt sich ohnehin wenig, so geht das auch gut. Da passt es gut, 800 kbit zu senden und 10*800 zu empfangen.

    Jemand, der nicht genug down Bandbreite hat, um alle Streams zu empfangen, schaltet auf eine 'nur Sprecher' (oder weniger Kacheln) Ansicht und fertig. Im Extremfall eben nur Audio.

    Künftig lässt sich das Problem auch mit 'Slices' lösen. Man sendet z.B. zwei streams: Der erste ist 360p, der zweite nur der Unterschied zwischen dem 360p Stream und 720p. Beides zusammen ist kaum größer als ein einziger 720p Stream. Ein leistungsfähiger Empfänger bekommt beides und zeigt 720p, ein schwächerer bekommt nur den 360p Stream. Das kann man natürlich über mehrere Ebenen machen. Es ist z.B. Bestandteil des kommenden AV1 Codecs.

    Transcoding findet statt auf Plattformen wie Twitch oder YouTube. Dort sind die Voraussetzungen anders. Dort wollen manche wirklich 4k, andere nur 240p. Für den Server ist bei 100000 Zuschauen gesparte Bandbreite wichtiger als Rechenleistung zum Transkodieren. Und durch die 'one way' Natur sind 10 Sekunden zusätzliche Latenz nicht schlimm.



    4 mal bearbeitet, zuletzt am 25.10.21 12:34 durch christian_k.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Junior BI Data Scientist (m/f/d)
    DMG MORI Management GmbH, Bielefeld
  2. Continuous Integration Engineer (m/f/d)
    I.K. Hofmann GmbH, Hildesheim
  3. Payroll Technology Solution Lead (m/f/x)
    Autodoc AG, Berlin, Szczecin (Polen), Cheb (Tschechien)
  4. Business Controlling Analyst (m/w/d)
    PHOENIX Pharmahandel GmbH & Co KG, Mannheim

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 11,99€
  2. 7,99€
  3. ab 79,99€
  4. 8,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de