#rC3 my Day Four

✍️ Written on 2020-12-30 in 1884 words. Part of cs IT-security

Motivation

I also joined the Chaos Communication Congress on Day Four. Sadly I missed “Better Justification for the Web” in the morning (why was it not on my list?). Because of this, I updated my personal “Fahrplan” with talks that have been rescheduled. The day started late since my girlfriend visited me spontaneously again.

Talks

Corona Warn App

Thomas Klingbeil is a software architect of the Corona Warn App (CWA). In this English talk, he split the talk into three sections: {Introduction to the app and its architecture, communication with the backend, risk calculation}. CWA contains a button “Have you been tested?” which leads to a digital form where you can fetch your test result. The Temporary Exposure Key (valid for 24h) is the central element from which other keys like the Rolling Proximity Identifier (valid for 10min) is derived. The architecture itself has many components (verification server, CDN, …). The European Federation Gateway Service (one component) allows to exchange data with service from other countries. In the following the data flow for test result retrieval using QR codes is illustrated:

  1. Scan QR code, contains GUID

  2. CWA stores GUID, hashed sent to Verification Server (VS)

  3. Verification server generated Registration Token (RT), stores hash(GUID) + hash(RT), returns RT

  4. App stores RT

  5. App polls for test results via RT

  6. The test result is provided by the Test Result Server (TRS) connected to Laboratory Information System (LIS)

  7. The test result is not stored long-torm on the verification server, but fetched from CWA.

  8. To verify test results, a TAN is requested by CWA from the verification server.

  9. CWA sends TAN together with the diagnosis keys from Exposure Notification Framework to the Corona-Warn-App Server.

  10. The CWA-Server verifies the TANs by asking the Verification Server.

In the following, he discusses the security of the architecture assuming a malicious user observes the network traffic. It can be detected that a user was tested. It can even be observed that someone was tested positive, because only users tested positive in this architecture contact the CWA-Server. As a result, plausible deniability properties have been integrated. Dummy requests are sent to diffuse network traffic. In the next section, the transmission risk level is discussed. The primary factor is whether the person is symptomatic and since when those symptoms occured. Here uncertainty can also be encoded; e.g. “symptoms occured within the last week for the first time”. An entire risk calculation chart was developed. Here the time of exposure is an important factor.

Data protection of decentralized Corona apps – Looking beyond the code

Kirsten Bock (background in law) & Rainer Rehak (CS & philosophy) talk about data protection

  • What is data protection? A research field. GDPR as EU law in this field.

  • What is the Corona-Warn app? “Trans-nation Bluetooth LE proximity tracing (like Ireland, Japan, Italy, etc)”. Includes app and server.

  • What is a data protection impact assessment (DPIA)? GDPR Art. 35 describes basic requirements of a DPIA aiming to detect problematic processing beforehand, needs to be conducted prior to processing. Voluntariness has to meet many preconditions. In general, no data on a personally used smartphone is anonymous. Anonymization of data uploaded to server is a difficult process. Server logging as topic. Anonymization can also be achieved on an organizational level. DPIA is suppossed to point out that Exposure Notification Framework is closed source and data protection guarantees cannot be given.

  • “CWA is a tech-based distraction from societal problem”

Inside xHamsters

In this German talk Yannah Alfering and Sebastian Meineck looked into xHamsters and how they enforce rules to avoid publication of illegal content. They published their findings in 6 articles on VICE and their stated goal was to “(VICE investigations) show for the first time how bad xHamster protects victims from sexualized violence”. Their motivation is given by publication of unconsentful content on xHamster in 2019. Chapters summarized:

  1. tl;dr: {Videos, stories, photos} versus {support team, reviewers club, automated tools}, system and rules are not publicly known, less than 130 voluntary reviewers are on this platform, consent on multiple levels (sex, recording, publication), content is online before reviewer’s club is triggered, review mechanism explained for pictures, videos are not reviewed by users these days anymore, gamification of reviewer system, number of necessary accepting reviews for flagged content is also unknown. One note said “for now we will keep all the copyright photos online”. Issues are:

    1. decide by photo: person is 18+?

    2. decide by photo: rape?

    3. be sure about rule violations by 100% (an internal message stated “Do not remove any content if you’re not 100% sure”)

    4. it is not intended to ask for documents about the people involved

    5. no rules for voyeurism

  2. Access to xHamster: With the help of an activistic sex worker, they created a fake profile and with patience they joined the Reviewer’s club (after more than 200 days). This allowed them to review photos and ask other reviewers which procedures they apply. They started to ask critical questions internally. How do they decide whether some content shows an under age person? The admin replied that there is no evidence that the person is under-age. Another reviewed answered “by gut feeling”.

  3. Internal rule set: They decided to publish the “New reviewers manual” into the public. They showed some examples for what is admissible/forbidden.

  4. Net politics: Contrast to youtube and facebook. Approaches:

    1. Reporting: NetzDG does not really help, mostly because the number of registered users (more than 2 mio. required) is too low. Voluntary cooperation with local executive is claimed but cannot be verified. “Digital Services Act” is an ongoing EU initiative which would affect reporting and cooperation.

    2. automated search: a free database by “National Center for Missing & Exploited Children” can be used, there does not seem to be any cooperation

    3. notice and takedown: a practice issues with notice and onus of proof

    4. measures before upload: in December 2020, xHamsters (after pornhub) stopped accepting sexual content from unverified accounts (apparently due to some American law from 2020-12-21)

  5. And now?!: Oct 2019 “freedom of sexual speech” → Dec 2020 “rather than police sexuality, we’ve often defaulted to greater freedom. That has to change”

  6. Q&A: In the Q&A, it was clarified that such journalistic work shall not be done without legal advice by a lawyer.

Infrastructure Review

heaven

1487 angels, 710 actually arrived, more than 300 did at least 1 shift, 17.5 weeks of done work, 125 angels helped to extinguish fire broken out during the event

signal angels

157 shifts for Q&A (5 unfilled) done by 61 angels (60 additional ones did not show up), pads for each session

Team Line producers (dt. “Aufnahmeleitung”)

“keep the show rolling”, 25 studios in Germany but 1 in Switzerland, 19 live broadcast channels, 350 talks and performances overall, 53 talks in the two main channels with 18 pre-recorded, prepared 63 speakers

C3VOC

CDN is built of 7 locations with a bandwidth of 80 Gb in total, c3voc started to develop KEVIN: Killer Experimental Video Internet Noise (kevin on github)

c3lingo

138 talks translated, only 5 translators in action, less language coverage than on other events, all talks on main tracks translated, interpreters spent 106 hours interpreting with 36 interpreters at work

c3subtitles

interpreters correct raw transcript by speech recognition software, 68 distinct angels working four shifts on average, 83% of our angels return for a second shift, {41 hours transcribed, 26 hours timed, and 51 hours checked} is on-going work, Kanban used to manage

phone operation center

1195 SIP extensions registered (\+500 from 36C3), 21k calls, one flamethrower operatable via DECT phone, SSTV servers

GSM

2 networks in Germany, 1 in Mexico, only 2 people unlike 36C3 with about ~10 people

haecksen

created a lot of goodies incl. masks, max 133 people in one BBB

ChaosPat:innen

65 mentees&mentors, two in-world mentee&mentor match-up sessions, world-map assembly built

c3adventure

since 2020-11-11 dev started, on day zero auth patch was merged, on day one, max 1642 simultaneously, 203 assemblies, 2.6 mio. tiles in total on all layers in 628 maps

hub

363 assemblies, 933 events, badges 403, documentation was not available yet, ~400 requests per second

c3auti

37 confirmed auti-angels, 200h of shifts, 10 orga mumbles before the event, 1k+ lines of panels documentation

c3ioc

c3 inclusion operation center, accessibility guides, CSS improved, “we have published a completely free and accessible CSS design template that features dark mode and an accessible font selection”

c3gelb

everything related to hygiene

chaos post

567 messages, 12 bounces, 43 TLDs delivered, delays between 4.2s and 7 hours overnight

c3infra

9 TB RAM, 1700 CPU cores, 1 SSD died, 5 dead RAID controllers, 100% uptime, ~300 nodes provisioned by ansible, 1105 peak user count, no IP addresses logged anywhere, minimal logging strategy applied, ddos24.net helped in stress test (millions of requests per second), 11600 watts of power, 620 Gbps total uplink capacity, 1.5 of 22 Gbps download was IPv6 traffic, received covid19 warning from a data center which did not affect the rc3 team, Jitsi with peak user count 1105 and peak outgoing video traffic 1.3 GBit/s (JVB), complete deployment with ansible (from 0 to Jitsi in 15min), there will be a blog post on our Jitsi Meet deployment, monitoring gave 34858 critical alerts and 13 070 warnings, 2 abuse emails received from Hetzner, 130k DNS updates, DNS/prometheus/grafana deployed on NixOS

Conclusion

On this concluding day of #rC3, I do not have talk recommendations, but the infrastructure review was very interesting for me as we have our linuxtage event ahead of us. I have planned some parts during the four days of #rC3. In the end, it was true that more and more parts were working as #rC3 progressed. I would like to thank a lot to the entire team for making this event possible. It was a huge effort and you made it possible. I have watched some interesting talks and it was fun. Dankon!

A German heise.de article summing up the event