Zoom

Zoom får nu måske end-to-end-kryptering

Via mobil.nu -

Zoom har via et opkøb, gjort det sandsynligt at de engang i fremtiden kan levere end-to-end-kryptering

Videochat-tjenesten Zoom, har ellers tidligere påstået at de havde end-to-end-kryptering, men måtte trække påstanden tilbage, da det viste sig at det ikke var sandt.

Med det nyeste opkøb af sikkerhedsfirmaet “KeyBase” ser det ud til at Zoom nu måske endelige kan indfri deres løfte.

Netop Zoom er blevet kritiseret for at slække på sikkerheden og ikke sikre at fremmede magter eller udefrakommende, ikke kan lytte med på videochattjenestens trafik.

P.t. er Zooms trafik krypteret med 256b AES-GCM, hvor nøglerne gemmes på Zoom’s egen server.





Gå til bund
Gravatar

#1 CBM 18. maj 2020 08:41

Måske eller måske ikke, det er spørgsmålet
https://fricomputer.dk https://retrohardwareheaven.blogspot.com/ #ComeToTheDuckSide www.duckduckgo.com, AMD + ASUS = kvalitet! #BringBackTheKeyboard #JackOn SailfishOS rocks! Stop using Google search.. use https://justsearchportal.com/ instead (includes DuckDuckGo)
Gravatar

#2 Claus Jørgensen 18. maj 2020 10:03

Altså det vil være end-to-end encryption på samme måde som Skype, Teams, og cirka alt andet non-p2p software.

Bruger A genererer en nøgle lokalt, og sender hans pub-key til serveren.
Bruger B modtager bruger A's nøgle fra serveren, og bruger den til at dekryptere bruger A's video/voice stream.

Men Zoom har stadigvæk pubkey, og kan derfor dekrypterer bruger A's (og bruger B) video/voice stream.

Og et man-in-the-middle attack mellem A<>Server, og Server<>B vil stadigvæk være muligt.
Gravatar

#3 Claus Jørgensen 18. maj 2020 10:19

Og det skal siges at overstående kun virker til 1:1. Og alternativet er at man kun bruger serveren til at sætte op en p2p forbindelse, og hvor pubkeys så udveksles via. p2p, altså uden om Zoom's serverer, hvilket så betyder at det kun er man-in-the-middle attacks der er et problem.

Men det betyder så desværre at det ikke er muligt at optage samtalen (meeting recording er en super populær feature i alle VoIP produkter til business).

Og det gør det rigtig rigtig langsomt at være i et conference call da man skal have pubkeys fra alle medlemmer, og hver eneste gang en ny medlem tilslutter opkaldet, og man kan ikke optimere ved at muxe alle de forskellige audio-streams into en enkelt stream, hvilket betyder at der er et enormt CPU og netværks forbrug hos hver enkelt bruger.

... sidstnævnte er hvordan Skype virkede da det var ren p2p. Og hvorfor alle altid klagede over problemer.

In short, p2p er sikkert, og kan virke nogenlunde til 1:1 opkald, men er praktiskt talt ubrugeligt til conference calls.

Imo. er der ingen måde at gøre conference calls rigtig sikker på. Enten skal man stole på MSFT/Google/Slack/ZOOM/Telefonselskabet, eller også skal man have en OnPrem løsning med sine egne encryption keys (WebEx, Pexip, etc.)
Gravatar

#4 larsp 18. maj 2020 11:47

Claus Jørgensen (2) skrev:
Og et man-in-the-middle attack mellem A<>Server, og Server<>B vil stadigvæk være muligt.

Der findes nu teknikker som Diffie hellman key exchange https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellm... (som SSH bruger) der muliggører at to parter opnår en fælles hemmelighed til at kryptere med, som man in the middle ikke kan udlede.

Det kræver så bare at man er sikker på man taler med den rigtige modpart mens man laver key exchange.
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#5 dub 18. maj 2020 15:04

Claus Jørgensen (2) skrev:
Altså det vil være end-to-end encryption på samme måde som Skype, Teams, og cirka alt andet non-p2p software.

Bruger A genererer en nøgle lokalt, og sender hans pub-key til serveren.
Bruger B modtager bruger A's nøgle fra serveren, og bruger den til at dekryptere bruger A's video/voice stream.

Men Zoom har stadigvæk pubkey, og kan derfor dekrypterer bruger A's (og bruger B) video/voice stream.

Og et man-in-the-middle attack mellem A<>Server, og Server<>B vil stadigvæk være muligt.

Er det virkligt rigtigt?
Jeg vil mene at:
Bruger A sender sin Pubkey A til Bruger B, Bruger B encoder sin trafik med Pubkey A. Bruger A decoder Bruger B trafik med Privkey A.
Det er nu kun Bruger A der kan decode trafik der er ment til Bruger A.
Cheerleader for videnskab.
Gravatar

#6 Claus Jørgensen 18. maj 2020 16:27

#5

Oh, right. Men det illustrer så endnu bedre hvorfor at det ikke vil virke særlig godt i et conference call med 20 mennesker
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login