Begutachtung 132/ME · XXVIII. GP

Stellungnahme Alterskontrolle - Audiovisuelle Mediendienste-Gesetz, KommAustria-Gesetz, Änderung (132/ME) Leider muss zunächst die Abwesenheit einer ausführlichen Technikfolgenabschätzung und einer Gegenüberstellung verschiedener Ansätze festgestellt werden, welche Kinder und Jugendliche vor Gefahren, insbesondere bei Social Media, schützen könnten. In der Folge werden die Risiken der gewählten Alterskontrolle kaum beleuchtet und sinnvolle Alternativen zum Schutz aller Nutzer*innen unzureichend berücksichtigt. Ich halte es für begrüßenswert, dass der Gesetzgeber suchtfördernde Designfunktionen wie "algorithmische Empfehlungssysteme" und "Infinite Scroll" benennt und problematisiert. Solche manipulativen Mechanismen bedrohen jedoch nicht nur Kinder und Jugendliche, sondern die digitale Gesundheit und Autonomie aller Menschen. Anstatt bei der Wurzel des Problems anzusetzen, indem der Gesetzgeber die Plattformen selbst, ihre Geschäftsmodelle und suchtfördernden Designelemente konsequent reguliert und verbietet, verlagert er die Verantwortung auf die Nutzer*innen und zwingt sie zu Alterskontrollen im Netz. In diesem Zusammenhang schließe ich mich der ausführlichen Stellungnahme von epicenter.works (Digitaler Ausweiszwang – Audiovisuelle Mediendienste-Gesetz, KommAustria-Gesetz, Änderung (132/ME)) an und unterstütze deren Forderungen. Ergänzend dazu möchte ich im Folgenden weitere Anmerkungen zur technischen Ausgestaltung der Altersverifikation einbringen: Registrierungsdruck und Datenschutzrisiken durch Fehlanreize Im Gesetzesentwurf heißt es: "Erfolgt der Zugang zur Video-Sharing-Plattform über ein individuelles Nutzerkonto, so ist die Altersverifikation hinsichtlich der Inhaberin bzw. des Inhabers des Nutzerkontos nur einmal durchzuführen, es sei denn, der Plattform-Anbieter verfügt über konkrete Anhaltspunkte dafür, dass das Nutzerkonto die Inhaberin bzw. den Inhaber gewechselt hat oder von mehreren Personen genutzt wird." Nutzer*innen, die eine Plattform bislang ohne Nutzerkonto verwendet haben, müssten bei jedem wiederkehrenden Besuch erneut die Alterskontrolle durchführen. Dadurch entsteht ihnen ein deutlicher Aufwandsnachteil gegenüber registrierten Nutzer*innen. Da wiederholte Alterskontrollen als störend empfunden werden, erzeugt die Regelung einen subtilen Druck: Nicht-registrierte Nutzer*innen werden dazu bewegt, doch ein Konto anzulegen ("Nudging through Friction"). Von diesem Effekt profitieren vor allem die Plattformen. Ein eigenes Nutzerkonto erleichtert es ihnen erheblich, personen- und geräteübergreifende Daten zu verknüpfen. Plakativ gesagt: Dieser Gesetzesentwurf liefert suchtfördernden Plattformen einen Hebel, um noch umfassender Daten zu sammeln und das Nutzerverhalten zielgerichteter zu steuern. Beschränkung der Attestierung auf Schlüsselmaterial in Hardware Vorgeschlagene Ergänzungen zum Gesetzestext (Formulierungsvorschlag) Software-Neutralität Software, die zur Durchführung von Altersverifikationen, zur Bereitstellung oder Nutzung digitaler Identitätsnachweise oder zur Erfüllung verwandter gesetzlicher Vorgaben eingesetzt wird, darf ihre Funktion nicht aufgrund der vom Nutzer gewählten Software-, App- oder Hardware-Umgebung verweigern oder einschränken. Dieses Verbot umfasst Einschränkungen aufgrund des Betriebssystems, benutzerdefinierter Firmware, des Bootloader-Status, und der OS- bzw. App-Integrität. Bereichsbeschränkte Schlüssel-Attestierung & Interoperabilität (1) Abweichend von der Software-Neutralität darf für die Nutzung von Altersverifikation oder zur eID-Nutzung verlangt werden, dass kryptografisches Schlüsselmaterial isoliert von einem zertifizierten Sicherheitsmodul generiert und verwaltet werden. Hardware- Attestierung darf ausschließlich zulässig sein, um zu prüfen, ob das Schlüsselmaterial von einem zertifizierten Hardwaremodul generiert wurde. (2) Wird ein Sicherheitsmodul verlangt, müssen alle Sicherheitsmodule akzeptiert werden, die durch ein offenes, transparentes und diskriminierungsfreies staatliches Verfahren zertifiziert wurden. Dies umfasst integrierte Smartphone-Sicherheitsmodule (Secure Elements), externe Chipkarten (Smartcards) sowie USB-/NFC-Tokens. Die Kommunikation mit externen Sicherheitsmodulen muss auf offenen Standards basieren und der Treibercode muss öffentlich verfügbar sein. Begründung Eine ausgewogene Bewertung von Attestierungsanforderungen erfordert eine sorgfältige Abwägung zwischen dem Umfang dessen, was attestiert wird, dem tatsächlichen Sicherheitsgewinn und den gesellschaftlichen Risiken. Dies gilt nicht nur für die hier konkret verhandelte Altersverifikation, sondern grundsätzlich für alle eID-Systeme und staatlich geforderten Verifikationsverfahren, bei denen das private Endgerät der Nutzer*innen eine Rolle spielt. Bei digitalen Identitätsnachweisen und Systemen zur Altersverifikation werden Vorgaben zur sicheren Handhabung von Zugangsdaten häufig als Mandat für eine vollständige Attestierung des Betriebssystems und der Anwendung interpretiert. Eine Ausweitung der Attestierung auf höhere Ebenen des Software-Stacks bringt jedoch einen verringerten zusätzlichen Sicherheitsgewinn: Während ein Hardware-Sicherheitsmodul eine überschaubare Angriffsfläche und Komplexität aufweist, ist ein Betriebssystem mit mehreren Millionen Codezeilen deutlich komplexer und anfälliger für Sicherheitsfehler. Kurzum: Reine Schlüssel-Attestierung ist sicher, solange das Sicherheitsmodul sicher ist. App-Attestierung benötigt hingegen zusätlich ein sicheres Betriebssystem. Damit ist App-Attestierung fragil, wodurch der erwartbare Sicherheitszugewinn eher gering ausfällt. In der Konsequenz führt App-Attestierung zu einer Sicherheitsasymmetrie zwischen Angreifer*innen und legitimen Nutzer*innen. Es ist nachgewiesen, dass selbst moderne Geräte mit den neuesten Sicherheits-Patches zur Laufzeit manipuliert werden können. Angreifer*innen, die im großen Stil operieren, haben starke Anreize, ein Gerät zu manipulieren und Laufzeit-Hooking- bzw. Spoofing-Techniken einzusetzen, um die App- Attestierung zu umgehen, und damit genau die Angriffe auszuführen, vor denen die App- Attestierung schützen soll. In der Praxis müssen Anbieter von Verifikationslösungen zahlreiche Geräte unterstützen, um eine breite Nutzung der App zu ermöglichen. Viele der sich im Umlauf befindlichen Geräte verwenden veraltete und unsichere Systemkomponenten. Das Schutzniveau der App- Attestierung generell gleicht damit praktisch dem des schwächsten unterstützten Geräts. Damit haben selbst weniger technisch versierte Angreifer*innen die Möglichkeit, die App- Attestierung zu umgehen. Umgekehrt werden ehrliche Nutzer*innen, die datenschutzfreundliche, sicherheitsgehärtete, angepasste oder selbst kompilierte Betriebssysteme nutzen, effektiv von grundlegenden Diensten ausgeschlossen. Dies führt zu dem praktischen Paradoxon, dass veraltete Geräte mit einem Standard-Betriebssystem und bekannten Sicherheitslücken akzeptiert werden, während vollständig aktualisierte, sicherheitsgehärtete alternative Betriebssysteme allein aufgrund fehlender Einträge in einer staatlichen Zertifizierungsliste abgelehnt werden. Darüber hinaus führt eine Attestierung auf Betriebssystemebene zu schweren Marktverzerrungen und systemischen Risiken. Der ressourcenintensive Prozess der Zertifizierung von Betriebssystemen schafft hohe administrative Hürden, die vor allem kleine Softwareanbieter, Nischen-Distributionen und Open-Source-Projekte übermäßig benachteiligen und die Dominanz etablierter Big-Tech-Monopole verstärken. Der wichtigste Punkt ist: Wird die Softwareausführung an eine Betriebssystem-Zertifizierung geknüpft, erhält der Staat ein mächtiges Druckmittel: Er kann von Herstellern übergriffige oder datenschutzfeindliche Funktionen verlangen, um ihren Marktzugang zu gewähren. Eine reine Schlüssel-Attestierung verhindert dieses Risiko vollständig. Eine Beschränkung auf reine Schlüssel-Attestierung kann ein guter Kompromiss sein. Das Sicherheitsmodul führt nur minimalen Code aus und hat dadurch eine sehr geringe Angriffsfläche. Es schützt dadurch das verwendete Schlüsselmaterial wirksam vor Klonen, Auslesen und Missbrauch. Wenn die Attestierung auf den Schlüssel fokussiert bleibt und externe Hardware (wie Smartcards oder USB-Token) mit offenen Treibern verfügbar sind, entsteht Vertrauen bei den Nutzer*innen, während gleichzeitig die staatliche Kontrolle über die Betriebssystemwahl vermieden wird.