Freigeben über


Kamera-Privatsphäre-Verschlüsse und Abschalter

Dieser Artikel enthält Richtlinien für den Geräteentwurf für Datenschutz-Verschlusse oder Kill-Schalter, Überlegungen zur Verschlusszustandserkennung und wie Verschlusse mit vorhandenen HLK-Anforderungen für Indikator-LEDs interagieren sollen.

Allgemeine LED-Anforderungen

Unabhängig von Verschluss- oder Kill-Schaltern erfordert HLK, dass eine sichtbare Indikator-LED eingeschaltet ist, wenn der ISP Sensordaten erfasst. Wenn die Kamera aktiv ist, muss bei RGB-Kameras eine einzelne sichtbare Wellenlänge LED (z. B. Weiß, Grün, Blau usw.) aktiviert sein:

RGB-Kameras eingeschaltet

Für Kameras mit einem RGB+IR-Sensor kann dies komplexer sein, da für die IR-Kamera eine Beleuchtungs-LED erforderlich ist, und die Beleuchtungs-LED kann eine sichtbare Wellenlänge (850 nm) oder unsichtbare Wellenlänge (940 nm) verwenden. Apps können zusätzlich entweder vom IR-Sensor allein, vom RGB-Sensor allein oder von beiden gleichzeitig streamen.

Designs mit einer sichtbaren Wellenlänge IR-Beleuchtung können sich entscheiden, die IR-Leuchter-LED als sichtbare Anzeige-LED zu verwenden. Dies bedeutet, dass, wenn die IR-Kamera selbst eingeschaltet ist, die HLK-Anforderungen dadurch erfüllt sind, dass die IR-Beleuchtungs-LED beleuchtet wird:

IR-Leuchtdiode aktiviert

Konstruktionen mit einem unsichtbaren Wellenlängen-IR-Strahler müssen eine sichtbare Wellenlängen-LED verwenden, um anzugeben, wann die IR-Kamera aktiv ist, um die HLK-Anforderungen (Hardware-Kompatibilitätsliste) zu erfüllen. Wir empfehlen, die Anzeige-LED für die Kameranutzung zu teilen, sodass die gleiche LED für sichtbares Licht aktiviert wird, wenn der IR-Sensor und/oder der RGB-Sensor eingeschaltet ist.

IR-Sensor und RGB-Sensor ist aktiviert

Es wird empfohlen, bei allen Designs die normale Betriebsanzeige-LED einzuschalten, wenn die IR- oder RGB-Kamera verwendet wird, unabhängig davon, ob die IR-LED-Beleuchtung eine sichtbare Wellenlänge verwendet oder nicht. Hier ist die vollständige Tabelle der wichtigsten LED-Anforderungen:

Streamzustand Sichtbare IR-LED (850 nm) Unsichtbare IR-LED (940 nm)
Kamera deaktiviert LEDs AUS LEDs AUS
Nur RGB-Kamera aktiviert In-Use-Indikator EIN, IR-Leuchter AUS In-Use-Indikator EIN, IR-Leuchter AUS
Nur IR-Kamera aktiviert Betriebsanzeige nicht erforderlich, aber ON empfohlen Betriebsanzeige EIN, IR-Strahler EIN
RGB- und IR-Kamera aktiviert Betriebsanzeige EIN, IR-Strahler EIN In-Use-Indikator EIN, IR-Strahler EIN

Hinweis

LED-Anforderungen können sich für Designs mit Kamera-Datenschutz-Verschluss oder Kamera-Kill-Schaltern unterscheiden. Siehe Kamera-Datenschutz-LED-Anforderungen für Informationen mit Kamera-Datenschutz-Verschluss und HLK LED-Anforderungen für Kamera-Kill-Schalter.

Always-on-KI-Erfahrungen (z. B. kamerabasierte menschliche Präsenz)

Für Geräte, die Kamera-basierte KI-Funktionen mit Always-On-Unterstützung bieten, wobei das KI-Silizium den Hauptkamerasensor gemeinsam nutzt, unterscheiden sich die LED-Anforderungen, wenn das speziell für Anwesenheitserkennung dedizierte Silizium ausschließlich auf die Kamera zugreift. Ausführliche Informationen finden Sie im Whitepaper zur Anwesenheitserkennung im Microsoft Partner Center.

Hardware-Datenschutzkontrollen

Wenn Kamera-Designs Hardware-Datenschutzkontrollen enthalten, gibt es zwei wichtige Grundsätze unserer Designrichtlinien.

  1. Geräte mit Datenschutzsteuerelementen müssen eine konsistente Benutzererfahrung und ein einheitliches Vertrauen in den Datenschutzstatus bieten:

    • Sobald ein Kunde lernt, wie der Verschluss auf dem Gerät aussieht und sich verhält, sollte dieses Wissen auf jedes Gerät angewendet werden, das über einen Verschluss verfügt.
  2. Unter keinen Umständen kann eine Kamera-Datenschutzkontrolle einen falschen Eindruck von Privatsphäre vermitteln:

    • Geräte dürfen beim wichtigsten Anliegen des Kunden keinen Datenschutzfehler aufweisen. Wenn der Datenschutzverschluss der Kamera geschlossen ist oder der Kamera-Kill-Schalter deaktiviert ist, erwarten Kunden, dass kein Bild aufgenommen werden kann, bis sie mit dem physischen Steuerelement interagieren, um die Datenschutzfunktion zu deaktivieren.

Typen von Steuerelementen

Zwei Arten von Datenschutzkontrollen sind definiert, Kamera-Datenschutz-Verschlusse (mechanische und elektromechanische) und Kamera-Kill-Schalter. Je nach Geräteformfaktor, BOM-Kostenzielen und Preis des Geräts kann ein OEM den Verschluss in einer dieser Formen einsetzen. Eine wichtige Konstante auf allen drei Ebenen ist, dass sie auf physischer oder Hardwareebene handeln müssen, was bedeutet, dass keine Software beteiligt ist, da Software kompromittiert werden kann.

Mechanischer Kameraprivatsphäre-Verschluss

Mechanische Verschlüsse sind das einfachste Design. Diese bestehen aus einer einfachen gleitenden Objektivabdeckung, die der Benutzer manuell betätigt, um die Kamera zu blockieren oder freizugeben. Sie sind mit einem undurchsichtigen Material konzipiert, das die Linse vollständig blockiert, wenn sie geschlossen wird. Dieses Design ist von Natur aus narrensicher, da es physisch nicht auf irgendeine Weise geöffnet werden kann, außer indem der Benutzer es verschiebt.

Elektromechanische Kamera Datenschutzverschluss

Elektromechanische Verschlusse sind elektrisch kontrollierte mechanische Verschlusse. Anstatt dass der Benutzer den Verschluss manuell öffnet oder schließt, öffnet/schließt der integrierte Verschluss als Reaktion auf das Drücken einer physischen Taste auf dem Gerät.

Hinweis

Obwohl diese Lösung im Allgemeinen Firmware erfordert, sollte sie von anderen Komponenten isoliert werden. Mit anderen Worten, der Verschlusscontroller und die Taste sollten keine Angriffsvektoren wie Kommunikationsbusse oder die Fähigkeit haben, firmware neu zu programmieren. Das Design muss Hardwareinteraktionen erfordern und nicht über Software gesteuert werden.

Kamera-Ausschalt-Schalter

Einige Geräte liefern heute eine Kamera-Kill-Switch-Funktion, die das Kameragerät physisch vom System trennt, wenn sie ausgeschaltet ist, und bietet eine Hardwaresteuerung, um den Kamerazugriff zu blockieren, ohne dass ein physischer Verschluss zum Abdecken des Objektivs/Sensors erforderlich ist. Obwohl dies robust gegen Angriffe ist, entsteht eine schlechte Benutzererfahrung. Durch das Entfernen des Geräts, wenn der Schalter ausgeschaltet ist, kann das System nicht erkennen, dass das Gehäuse noch eine Kamera enthält, aber dass er ausgeschaltet ist. Dies ist aus UX-Sicht problematisch, wenn die Kamera unbeabsichtigt von einem Benutzer deaktiviert wird, der den Schalter nicht erkennt, da Anwendungen berichten, dass keine Kameras angeschlossen sind. Es kann auch dazu führen, dass bestimmte Anwendungen abstürzen oder falsch wirken, wenn die Kamera während der Verwendung entfernt oder angezeigt wird, während die App ausgeführt wird.

Dementsprechend empfiehlt oder unterstützt Microsoft nicht die Verwendung von Kamera-Kill-Schaltern, die die gesamte Kamera vom System entfernen. Stattdessen empfehlen wir eine von zwei Lösungen:

  1. Ein physischer Verschluss, wie bei mechanischer Kamera-Privatsphäreverschluss und elektromechanischer Kamera-Privatsphäreverschluss beschrieben.

  2. Ein Kill-Schalter, der den Sensor und nicht den ISP trennt und bewirkt, dass der ISP schwarze Frames synthetisiert.

Für die zweite Lösung wird die Kamera weiterhin im System angezeigt, und Apps können sie weiterhin verwenden. Der ISP reagiert auf alle Befehle (Start-/Stopp-Streaming, DDIs wie Helligkeit oder Kontrast, Medientypänderungen usw.) normal, unabhängig davon, ob der Kill-Schalter aktiv ist oder nicht. Wenn der Kill Switch aktiviert wird, erfasst der ISP jedoch nicht mehr echte Daten vom Sensor und synthetisiert stattdessen schwarze Frames, die aus sicht der Anwendung transparent sind.

Jalousien mit mehreren Kameras auf einem Panel

Wenn Kunden Geräte mit Verschluss verwenden (z. B. Verschlusse mit mehreren IR- und RGB-Kameras auf einem Panel), erwarten sie, dass der Datenschutz vor unerwartetem Kamerazugriff geschützt ist, wenn der Verschluss geschlossen ist. Wenn Systeme zwei Kameras auf demselben Panel haben, z. B. eine RGB- und IR-Kamera zur Unterstützung von Windows Hello, ist es wichtig, sicherzustellen, dass der Verschluss kein falsches Sicherheitsgefühl gibt. Es wird nicht erwartet, dass Kunden verstehen, dass es möglicherweise einen zweiten Kamerasensor für Windows Hello gibt. Manche Geräte verwenden jedoch einen einzigen Sensor für RGB+IR. Aus diesem Grund muss der Verschluss alle Kameras auf dem Panel abdecken.

Die Sicherstellung, dass Verschlusse und Kill-Schalter auf die IR-Kamera angewendet werden, ist von größter Bedeutung, da auf die IR-Kamera von Anwendungen zugegriffen werden kann und relativ präzise Bilder der Szene erzeugt werden können, wie unten dargestellt. Wenn der IR-Sensor nicht verdeckt wird, würde dies ein trügerisches Sicherheitsgefühl und einen Vertrauensbruch der Benutzer in den Datenschutznutzen des Verschlusses bedeuten.

IR-Bild vom Microsoft-Referenzsensor

Hinweis

Windows Hello Face erfordert sowohl eine RGB- als auch eine IR-Kamera. Wenn die RGB-Kamera verdeckt ist, funktioniert Windows Hello nicht ordnungsgemäß. Sowohl RGB- als auch IR-Datenströme werden zur Ermöglichung von Antispoofing-Gegenmaßnahmen verwendet.

Anleitung zur physischen Verschlussgestaltung (mechanische oder elektromechanische)

Wenn ein Kunde ein Gerät mit einem physischen Verschluss verwendet, gibt die Anwesenheit des Verschlusses eine starke konkludente Erwartung über den Grad der Privatsphäre, den er bietet. Bei einem Gerät mit einem verschließbaren Objektivverschluss erwartet der Benutzer, dass er bei geschlossenem Verschluss vor unerwartetem Kamerazugriff geschützt ist. Es ist entscheidend, dass die Implementierung des Features den implizierten Erwartungen gerecht wird, sonst verliert es das vertrauen.

Darüber hinaus besteht das gesamte Konzept eines Datenschutzverschlusses darin, eine Sicherheitsschicht bereitzustellen, die gegen praktischen Softwareangriffe gehärtet wird. Mit anderen Worten: Wenn das Gerät über einen Verschluss verfügt und das System vollständig von Schadsoftware kompromittiert wird, kann diese Software den Datenschutz des Benutzers nicht gefährden. Um es einfach zu sagen, ist die Erwartung, dass der Verschluss nur dann den Zustand ändern kann, wenn der Benutzer physisch mit dem Hardware-Verschluss-Steuerelement auf dem Gerät interagiert.

Überlegungen zur mechanischen Konstruktion

Physische Verschlusse, ob manuell oder elektromechanisch betätigt, werden voraussichtlich aus einem undurchsichtigen Material hergestellt, das den Sensor vollständig blockiert, wenn er geschlossen wird und für das nackte Auge sichtbar ist:

Undurchsichtiges Material blockiert den Sensor, ist bei geschlossenem Zustand mit dem bloßen Auge sichtbar

Wie in Läden mit mehreren Kameras auf einem Panel beschrieben, müssen bei Geräten mit separater IR- und RGB-Kamera auf demselben Panel beide Sensoren gleichzeitig blockiert sein, wenn der Verschluss geschlossen ist. Gehen Sie davon aus, dass ein Dualsensordesign wie folgt aussieht:

Design des dualen Sensors

Wenn der Verschluss geschlossen ist, muss er den RGB-Sensor abdecken, es ist optional, den IR-Sensor abzudecken:

bei geschlossenem Verschluss müssen beide Sensoren abgedeckt werden

Hinweis

Wir unterstützen derzeit eine Ausnahme für Kameras, deren mechanische Verschlussdesigns die IR-Kamera nicht abdecken. Wenn ein physischer Verschluss die RGB-Kamera verdeckt, ist es akzeptabel, dass die ISP-Firmware die Bildausgabe der IR-Kamera verwerfen und durch ein synthetisiertes schwarzes Bild ersetzt. Wenn der IR-Sensor jedoch für die Anwesenheitserkennung verwendet wird, wird empfohlen, den IR-Sensor nicht abzudecken und sicherzustellen, dass der Anwesenheitssensor funktionsfähig ist. Ausführliche Informationen finden Sie im Whitepaper zur Anwesenheitserkennung im Microsoft Partner Center. Ein zukünftiges HLK-Update wird diese Ausnahme übernehmen und nur physische Verschlusse erfordern, um die RGB physisch zu verdecken, um die Stabilität der Lösung und einen stärkeren Schutz der Kundendaten zu gewährleisten.

Überlegungen zum Kameraverhalten

Wenn eine Kamera mit einem physischen Verschluss ausgestattet ist, muss die Kamera unabhängig vom Verschlusszustand weiterhin normal arbeiten. Wenn eine App von der Kamera streamt, erfasst und übertragen sie auch dann reale Sensordaten, wenn der Verschluss geschlossen ist. Eine vollständige Blockierung des Sensors durch einen geschlossenen Verschluss sollte ein Bild erzeugen, das schwarz oder nahezu schwarz ist.

OEMs können das Bild durch ein statisches Bild ersetzen, wenn der Verschluss geschlossen ist (z. B. ein Bild einer durchgestrichenen Kamera). Dieses Bild muss statisch sein und kann nicht von Software geändert werden, um vor Exploits zu schützen. Bei Geräten mit Datenschutzverschluss kann der Bildaustausch innerhalb des ISP oder innerhalb des Treibers erfolgen, obwohl der Austausch innerhalb des ISP empfohlen wird, die Notwendigkeit von DMFTs zu verringern und dem Hostgerät Last hinzuzufügen.

LED-Anforderungen für den Kamera-Privatsphäre-Verschluss

DIE LED-Anforderungen müssen den anforderungen entsprechen, die für allgemeine LED-Anforderungen gelten. Dies bedeutet, dass, wenn eine Kamera auf dem Panel eingeschaltet ist, eine sichtbare Wellenlängenkamera in der Betriebsanzeige LED eingeschaltet bleiben muss, unabhängig davon, ob der Verschluss geöffnet oder geschlossen ist. Es ist jedoch akzeptabel, dass das physische Design des Verschlusses die LED abdeckt, wenn der Verschluss geschlossen ist. Die folgenden Diagramme veranschaulichen ein Szenario, wenn die Kamera aktiv streamt:

Kamera wird aktiv gestreamt

Bei Designs mit einer IR- und RGB-Kamera möchten einige Hersteller möglicherweise die IR-Beleuchtungs-LED deaktivieren, wenn die IR-Kamera verwendet wird, während der Verschluss geschlossen ist. Wir raten davon ab, da es zusätzliche Komplexität für wenig Nutzen hinzufügt; Die IR-Kamera ist nur aktiv, wenn Windows Hello ausgeführt wird, und Windows Hello zeigt während dieser Zeit eine Meldung an, dass versucht wird, Sie anzumelden, aber der Verschluss ist geschlossen. Details finden Sie unter Kill Switch-Implementierung .

Wenn jedoch eine 840 nm (infrarote) IR-Beleuchtungs-LED nicht die einzige Betriebsanzeige-LED für die IR-Kamera ist (z. B. kann eine normale weiße/grüne/blaue LED leuchten, wenn die IR-Kamera aktiv ist), kann ein Design die IR-Beleuchtungs-LED ausschalten, wenn der Verschluss geschlossen ist.

Verschlusszustands-Umschaltmechanismen

Geräte, die Datenschutz-Verschlusse implementieren, dürfen keine Form der Softwaresteuerung des Verschlusses zulassen und dürfen den Verschluss nur öffnen oder schließen, wenn der Benutzer explizit mit dem Verschlusssteuerelement interagiert. Bei dieser Verschlusssteuerung kann es sich um einen mechanischen Schieberegler oder eine physische Taste, die einen elektromechanischen Verschluss aktiviert. Es kann keine Software den Verschlusszustand ändern, auch wenn ein Hardwaresteuerelement die Software außer Kraft setzen und den Verschluss geschlossen halten kann, da ein geschlossener Verschluss nicht immer bedeutet, dass die Datenschutzsteuerung aktiviert ist. Ebenso kann der Verschluss aus demselben Grund nicht öffnen oder schließen, wenn eine App die Kamera verwendet. Wenn der Benutzer auf das Gerät blickt und den Verschluss sieht, muss er unmissverständlich feststellen können, dass seine Privatsphäre geschützt ist, bis sie physische Maßnahmen ergreifen, um den Verschluss zu öffnen.

Verschlusszustandserkennung und -berichterstattung

Viele der Probleme mit In-Market-Kamera-Datenschutzdesigns stammen aus Situationen, in denen ein Benutzer unbeabsichtigt den Verschluss schließt und nicht herausfinden kann, warum seine Kamera ein leeres Bild erzeugt oder nicht funktioniert. Dementsprechend basiert ein wichtiger Teil des Windows-Datenschutz-Verschlussfeatures darauf, dass die Kamera ihren Verschlussstatus zuverlässig melden kann. Mit diesen Informationen können Anwendungen den Benutzer darüber informieren, dass der Verschluss geschlossen ist, damit er entsprechend reagieren kann. Verschlusszustandsänderungen sollten erkannt und so schnell wie möglich gemeldet werden, nachdem das Ereignis eintritt.

Es werden zwei Methoden zur Erkennung des Verschlusszustands, physischer Sensoren und firmwarebasierter Erkennung vorgeschlagen. Beide Methoden melden den erkannten Verschlusszustand über CT_PRIVACY_CONTROL , wenn sie von einem UVC-Gerät stammen, oder KSPROPERTY_CAMERACONTROL_PRIVACY , wenn sie von einem AVStream- oder DMFT-Treiber stammen.

Weitere Informationen finden Sie in der Benachrichtigung über den Datenschutz.

Physischer Zustandserkennungssensor

Der Verschlusszustand kann mit einem physischen Sensor erkannt werden, der erkennen kann, ob der Verschluss geöffnet oder geschlossen wird. Physische Sensoren können den Verschlusszustand deterministisch melden und können eine zuverlässigere Erfahrung bieten. Microsoft bietet keine spezifischen Anleitungen für Sensordesigns oder spezifische Empfehlungen für sensortechnische Technologien.

ISP Firmware-basierte Zustandserkennung

Einige Designs können einen physischen Verschluss überspringen und stattdessen die Firmware innerhalb des ISP verwenden, um das Bild zu verarbeiten und den abgeleiteten Verschlusszustand zu melden. Eine solche Lösung würde das erfasste Bild in der Firmware analysieren und mit einem Schwellenwert vergleichen, um festzustellen, ob der Verschluss geschlossen zu sein scheint. Dies ist eine kostengünstige Lösung, da keine neuen Teile erforderlich sind und auch Dinge wie Band über einen Sensor erkennen können. Bei der Auswahl eines solchen Designs gibt es jedoch zwei wichtige Überlegungen:

  1. Das Design kann einen geschlossenen Verschluss in dunklen Umgebungen falsch melden. Es wird jedoch erwartet, dass dies ein minimales Risiko/Problem ist, da die Kamera in einer solchen Umgebung mit geringem Licht trotzdem nicht verwendbar wäre.

  2. Sofern der ISP nicht in der Lage ist, regelmäßig Stichproben vom Sensor zu entnehmen, wann immer es aus D3 heraus ist, verhindert diese Methode, dass Apps genaue Sensorzustandsdaten abfragen können, bis sie einen Stream von der Kamera starten.

Die zweite Überlegung stellt eine Herausforderung dar. Wenn die Kamera den Verschlussstatus nicht meldet, wenn es nicht gestreamt wird, aber eine App zum Überprüfen und Reagieren auf den Verschlusszustand vor dem Streaming geschrieben wurde, können schlechte Dinge passieren. Als Reaktion auf das Feedback, das wir von Partnern erhalten haben, wurde diese Anforderung entspannt. Darüber hinaus aktualisieren wir die API-Dokumentation, um Softwareentwicklern davon abzuraten, Entscheidungen basierend auf dem Verschlusszustand zu treffen, der gemeldet wird, wenn nicht gestreamt wird. Beispielsweise empfehlen wir App-Entwicklern explizit, die Kamera nicht zu deaktivieren, wenn der Verschluss meldet, dass sie geschlossen ist.

Um das Risiko von Kompatibilitätsproblemen mit Apps zu vermeiden, die diesen Rat nicht einhalten, wird von Kameras, die den Verschlusszustand nicht erkennen können, erwartet, dass der Verschluss als geöffnet gemeldet wird, solange nicht gestreamt wird. Wenn die Kamera den Verschlusszustand erkennen kann, wenn sie nicht streamt, wird erwartet, dass sie den Verschlusszustand erkennt und meldet, solange sie sich nicht im Zustand D3 befindet.

Hinweis

Bildanalysebasierte Verschlusserkennungsalgorithmen sollten immer in der Firmware und nicht in einem Treiber implementiert werden, um eine höhere CPU-Auslastung und maximale Stabilität zu vermeiden.

Hier ist ein Diagramm, das das erwartete Verhalten für ein Gerät mit einem Kamera-Datenschutzverschluss veranschaulicht:

erwartetes Verhalten für Gerät mit Kamera-Datenschutz-Verschluss

Zusammenfassungstabelle zum Verhalten des Kamera-Privatheitsverschlusses

Die folgende Tabelle fasste das erwartete Verhalten einer Kamera mit einem Kamera-Datenschutzverschluss (manuell oder elektromechanisch) zusammen:

ISP-Status Verschlusszustand Sichtbare Anzeige-LED Bild, das auf den PC gestreamt wurde Der gemeldete Zustand von CT_PRIVACY_CONTROL
Leerlauf/D3 Geöffnet Aus* Nicht verfügbar Geöffnet
Leerlauf/D3 Geschlossen Aus* Nicht verfügbar Geöffnet**
Streaming (beliebige App) Geöffnet Auf* Erfasstes Sensorbild Geöffnet
Streaming (beliebige App) Geschlossen Auf* Erfasstes Sensorbild Geschlossen

(*) Details zu den LED-Anforderungen für Indikatoren finden Sie unter Anforderungen für die Kamera-Datenschutz-LED und Mechanismen zum Umschalten des Verschlussstatus.

(**) Ausführliche Informationen finden Sie unter Verschlusszustandserkennung und -berichterstellung , in einigen Szenarien wird der Verschlusszustand weiterhin aktualisiert, wenn es nicht gestreamt wird.

Designleitfaden für Not-Aus-Schalter

Wenn ein Kunde ein Gerät mit einem Kill Switch verwendet, setzt er Vertrauen in einen Hardware-Schalter, um sich robust gegen alle Anwendungen zu schützen, die versuchen, sein Bild aufzunehmen. Einfach gesagt: Wenn mein Gerät über einen Kill Switch verfügt und der Kill Switch aktiviert ist, ist mein Datenschutz vor unerwartetem Kamerazugriff geschützt. Es ist entscheidend, dass die Implementierung des Features den implizierten Erwartungen gerecht wird, sonst verliert es das vertrauen.

Darüber hinaus besteht das gesamte Konzept eines Kill Switch darin, eine Sicherheitsebene bereitzustellen, die gegen praktische Softwareangriffe gehärtet ist. Wenn das Gerät über einen Kill Switch verfügt und das System vollständig durch schadhafte Software kompromittiert wird, kann diese Software den Kill Switch nicht außer Kraft setzen und den Datenschutz des Benutzers gefährden. Einfach ausgedrückt, ist die Erwartung, dass *der Kill Switch nur aktiviert/deaktiviert werden kann, wenn der Benutzer physisch mit dem Gerät interagiert.

Im Vergleich zu Datenschutz-Verschluss-Designs sind Kill-Schalter komplexer und stellen größere Herausforderungen dar, um vertrauenswürdig geliefert zu werden. Dies liegt daran, dass sie die gleiche Erwartung an Robustheit tragen (ein physischer Schalter wird erwartet, dass er in allen Situationen reibungslos funktioniert), aber sie bieten nicht die Gewissheit, die ein physischer Verschluss über der Linse bietet. Dies bedeutet, dass Geräte, die Kill-Switches anbieten, eine konsistente, klare und zuverlässige Erfahrung erzeugen müssen.

Kill Switch-Funktionalität

Kill Switches funktionieren, indem sie die ISP-Firmware anweisen, die Erfassung vom Sensor zu beenden und stattdessen ein schwarzes Bild zu synthetisieren. Auf diese Weise ist die Kamera immer noch verfügbar und funktionsfähig aus der Sicht von Anwendungen, aber es gibt keine echten Sensordaten, die in das Hostbetriebssystem übertragen werden, wenn der Kill-Schalter aktiv ist. Ein robustes Design würde wie folgt funktionieren:

  1. Physisches Signal vom Switch stellt eine Verbindung mit einer GPIO auf dem ISP her, um anzugeben, ob der Schalter aktiv ist oder nicht.

  2. Wenn der Kill Switch aktiv ist, ist der ISP:

    1. Trennt den Sensor elektrisch

    2. Beginnt mit der Synthesierung von schwarzen Frames, um echte Frames vom getrennten Sensor zu ersetzen

    3. Meldet, dass der Sichtschutz über die Privatsphäre-Benachrichtigung geschlossen ist.

In der Praxis ist ISP-Silizium, das diese volle Erfahrung unterstützt, einschließlich einer elektrischen Trennung des Sensors, wenn der Kill Switch GPIO aktiv ist, noch nicht auf dem Markt verfügbar. Dementsprechend erfordern aktuelle Designs eine Änderung von Schritt 2a oben, um "den Sensor zu beenden oder die Sensordaten innerhalb der Firmware zu verwerfen". Wir planen die Zusammenarbeit mit ISP-Anbietern, um die Notwendigkeit dieser Anpassung in zukünftigen Siliziumprodukten zu mindern.

Hinweis

Es ist wichtig, dass die Kill Switch-Funktionalität in der ISP-Firmware und nicht innerhalb eines Treibers implementiert wird, der auf dem Hostbetriebssystem ausgeführt wird. Echte Bilddaten vom Sensor dürfen nicht in das Betriebssystem übertragen werden, wenn sich der Kill Switch im Zustand "Kill" befindet.

Wie bei Privacy Shutters können OEMs das Bild durch ein statisches Bild ersetzen, wenn sich der Kill Switch im Zustand "Kill" befindet. Der Austausch des Images kann innerhalb des ISP oder des Treibers durchgeführt werden, wobei ein Austausch innerhalb des ISP empfohlen wird, um das Erfordernis von DMFTs zu verringern und die Belastung des Hostgeräts zu vermeiden. Wenn die Bildersetzung vom Treiber ausgeführt wird, beachten Sie die Anforderung, dass echte Bilddaten nicht in das Betriebssystem übertragen werden, wenn der Kill-Schalter im Zustand "kill" weiterhin aktiviert ist.

Kill Switch-Implementierung

Der Kill Switch-Zustand darf nicht softwaregesteuert sein, andernfalls könnte eine schädliche Anwendung das Steuerelement schreiben, um den Kill Switch zu aktivieren oder zu deaktivieren. Sie sollten von einem Switch gesteuert werden, der mit einem GPIO auf dem ISP verbunden ist.

Es ist wichtig, dass, wenn die Kamera-Sicherheitsabschaltungen deaktiviert sind, die Kamera im System weiterhin angezeigt wird und Apps weiterhin von ihr streamen können, nur das Bild schwarz wird. Frames werden weiterhin an das Betriebssystem übermittelt, und die Kamera reagiert weiterhin auf Steuerelemente; Apps wissen nicht, dass sich der Switch im Zustand "Kill" befindet, es sei denn, die App verwendet die CameraOcclusionInfo-APIs . Dadurch kann die Kamera über ein Hardware-Steuerelement deaktiviert werden, ohne verwirrende Meldungen "Kamera nicht gefunden" anzuzeigen oder das Risiko einzugehen, dass bestimmte Anwendungen beim Umlegen des Schalters abstürzen.

Wie in Shutters mit mehreren Kameras auf einem Panel beschrieben, müssen Geräte mit separaten IR- und RGB-Kameras auf demselben Panel beide Sensoren gleichzeitig deaktiviert haben, wenn der Kill-Schalter aktiviert wird.

HLK LED-Anforderungen

HLK setzt voraus, dass die Indikator-LED eingeschaltet ist, wenn der ISP Sensordaten erfasst. Die Aktivierung des Kill-Schalters bedeutet, dass der ISP die Erfassung realer Daten vom Sensor beenden muss, sodass die LED auch mit dem Kill-Schalter ausgeschaltet wird. Dies vermeidet Verwirrung oder Vertrauensverletzungen, wenn der Kunde eine Leuchtanzeige oder IR-Beleuchtungs-LED sieht, wissen sie, dass die Software derzeit ihr Bild erfasst, und wenn sie keine beleuchtete LED sehen, wissen sie, dass sie nicht erfasst werden.

Meldung des Kill-Switch-Zustands

Der Status des Kill-Schalters sollte über CT_PRIVACY_CONTROL (sofern es von einem UVC-Gerät stammt) oder KSPROPERTY_CAMERACONTROL_PRIVACY (wenn dieser von einem AVStream- oder DMFT-Treiber stammt) gemeldet werden. Der Zustand des Kamera-Kill-Schalters sollte gemeldet werden, wenn der ISP nicht mehr im D3-Zustand ist.

Weitere Details finden Sie unter Datenschutz-Verschluss-/Schalterbenachrichtigung .

Kill Switch Zustandsbericht

Zusammenfassungstabelle für Kill Switch-Verhalten

In der folgenden Tabelle wurde das erwartete Verhalten einer Kamera mit einem Kamera-Kill-Schalter zusammengefasst:

ISP-Status Zustand des Notausschalters Sichtbare Anzeige-LED Bild, das auf den PC gestreamt wurde Gemeldeter CT_PRIVACY_CONTROL Zustand
Leerlauf/D3 Laufen Aus* Nicht verfügbar Öffnen
Leerlauf/D3 Töten Aus* Nicht verfügbar Schließen
Streaming (beliebige App) Laufen Auf* Erfasstes Sensorbild Öffnen
Streaming (beliebige App) Töten Aus* Leere synthetisierte Rahmen Schließen

Einzelheiten zu den Anforderungen der Anzeigelicht-LEDs finden Sie unter Kamera-Datenschutz-LED-Anforderungen und Verschlussstatus-Umschaltmechanismen.

ISV-Leitfaden für Verschluss-/Schalterereignisse

Wenn eine Kamera mit einem Datenschutz-Verschluss oder Kill-Schalter den Anweisungen in dieser Dokumentation folgt, wird der Verschluss-/Schalterzustand beim Streamen der Kamera an das Betriebssystem gemeldet. Anwendungen, die die Kamera verwenden, können dann Verschlusszustandsänderungsereignisse überwachen und entsprechend reagieren, z. B. durch eine hilfreiche Benachrichtigung, dass die Kamera durch einen Verschluss oder Schalter blockiert wird.

Weitere Informationen finden Sie in den folgenden APIs:

CameraOcclusionInfo-Klasse

CameraOcclusionState-Klasse

VideoDeviceController.CameraOcclusionInfo-Eigenschaft