Die ZETA Spezifikation definiert eine Reihe von Sicherheitsanforderungen, zum einen direkt als Anforderung in der gemspec_ZETA selbst, zum anderen indirekt über referenzierte Dokumente wie gemspec_krypt, OWASP Top 10, oder BSI TR-03161-1.
Nicht alle diese Anforderungen können durch das ZETA-SDK sichergestellt werden. Zum Beispiel gibt es Anforderungen, die sich auf das sichere Verteilen einer App beziehen - dies kann nur durch den Client-Hersteller abgebildet werden.
Die hier bereitgestellte Liste von Anforderungen wurde identifiziert als nicht durch das ZETA-SDK abbildbar. Sie sind damit Hinweise für die Sicherheitsprüfungen des Clients, in dem das ZETA-SDK verwendet wird.
Die Anforderungen wurden nach den MASVS Kategorien klassifiziert.
Storage
Die API des ZETA-SDK sieht vor, dass dem SDK eine - im Besten Fall existierende - Funktionalität zur sicheren Ablage von sensitiven Daten wie Access Token etc zur Verfügung gestellt wird. Dies dient der Wiederverwendung existierender (bereits geprüfter) Funktionalität und der Vermeidung von Doppelimplementierungen. Dies bedeutet aber auch, dass Anforderungen im Bereich Storage an den Client-Hersteller gerichtet sind.
Die Anforderungen stammen im Wesentlichen aus der BSI TR-03161-1.
Afo
Beschreibung
Bemerkung
O.Data_1
Die Werkseinstellung der Anwendung MUSS die maximale Sicherheit bieten.
O.Data_2
Die Anwendung MUSS sensible Daten verschlüsselt speichern. Die betriebssystemeigene Verschlüsselung des Dateisystems genügt nicht. Das Schlüsselmaterial für diese Verschlüsselung DARF NICHT unverschlüsselt persistiert werden. Dies gilt sowohl für flüchtiges Ablegen (z. B. im Arbeitsspeicher), als auch für dauerhaftes Speichern (z. B. in einer Cloud-Umgebung). Eine hardwareunterstützte Schlüsselverwaltung der Plattform SOLL bevorzugt verwendet werden.
Sichere Storage ist an den aufrufenden Client delegiert
O.Data_3
Die Anwendung SOLL sensible Daten in einem vor Einsicht und Manipulation besonders geschützten Bereich ablegen.
Sichere Storage ist an den aufrufenden Client delegiert
O.Data_4
Die Anwendung DARF Ressourcen, die einen Zugriff auf sensible Daten ermöglichen, gegenüber Dritten NICHT verfügbar machen.
Sichere Storage ist an den aufrufenden Client delegiert
O.Data_7
Sofern die Anwendung an ein Hintergrundsystem angebunden ist, SOLL die Speicherung und Verarbeitung von sensiblen Daten im Hintergrundsystem erfolgen.
Das SDK speichert keine sensiblen Daten, sondern leitet sie nach Spezifikation durch an den Fachdienst
O.Data_16
Es MUSS vom Hersteller sichergestellt werden, dass bei der Deinstallation der Anwendung alle sensiblen Daten und anwendungsspezifischen Anmeldeinformationen auf dem Endgerät nicht mehr zugreifbar sind.
O.Data_17
Die Anwendung MUSS dem Nutzer die Möglichkeit geben, dass alle sensiblen Daten und anwendungsspezifischen Anmeldeinformationen vollständig gelöscht bzw. unzugänglich gemacht werden.
O.Data_18
Um dem Missbrauch von sensiblen Daten nach einem Geräteverlust entgegenzuwirken, KANN die Anwendung einen Kill-Switch realisieren, d. h. ein absichtliches, sicheres Überschreiben von Nutzerdaten im Gerät auf Anwendungsebene, ausgelöst durch das Hintergrundsystem. Der Hersteller MUSS die Auslösung des Kill-Switches durch den Anwender über das Hintergrundsystem durch starke Authentifizierungsmechanismen vor missbräuchlicher Nutzung schützen.
O.Data_12
Sensible Daten wie biometrische Daten oder private Schlüssel DÜRFEN NICHT aus der Komponente, auf der sie erzeugt wurden, exportiert werden.
Die Speicherung des Client Instance Keys ist aktuell an den Client delegiert. In zukünftigen Versionen wird die Speicherung in einem Plattform-TPM stattfinden
O.Data_13
Die Anwendung MUSS Funktionen des Betriebssystems zur Unterbindung der Anzeige sensibler Daten und des Zugriffs für Dritte und der Speicherung des Bildschirms (z. B. Screenshots und Anzeigen für das App-Switching) nutzen.
O.Data_14
Die Anwendung MUSS sicherstellen, dass im gesperrten Zustand des Endgeräts alle sensiblen Daten verschlüsselt sind.
Crypto
Die TR-03161-1 Anforderungen werden hier relevant, da die Speicherung der Schlüssel zum aktuellen Zeitpunkt nicht im TPM stattfindet sondern im delegierten Storage.
Afo
Beschreibung
Bemerkung
O.Crypt_6
Alle kryptographischen Schlüssel SOLLEN in einer vor Manipulation und Offenlegung geschützten Umgebung liegen.
O.Data_14
Die Anwendung MUSS sicherstellen, dass im gesperrten Zustand des Endgeräts alle sensiblen Daten verschlüsselt sind.
O.Crypt_7
Alle kryptographischen Operationen SOLLEN in einer vor Manipulation und Offenlegung geschützten Umgebung stattfinden.
Authentication und Authorization
Afo
Beschreibung
Bemerkung
O.Auth_13
Authentisierungsdaten, wie bspw. Session-Identifier bzw. Authentisierungstoken, MÜSSEN als sensible Daten geschützt werden.
O.Auth_9
Die Anwendung MUSS nach einer angemessenen Zeit in der sie nicht aktiv verwendet wurde (idle time) eine erneute Authentisierung fordern.
Die gematik erfordert eine regelmäßige Aktualisierung des Access Tokens; für eine Authentisierung gegen die App / das Primärsystem ist das im Scope des Client-Herstellers
O.Auth_8
Wurde die Anwendung unterbrochen (in den Hintergrundbetrieb versetzt), MUSS nach Ablauf einer angemessenen Frist (Grace Period) eine erneute Authentisierung durchgeführt werden.
Network
Afo
Beschreibung
Bemerkung
O.Ntwk_8
Die Anwendung MUSS für alle Verbindungen Log-Dateien vorhalten. Diese SOLLEN an das Hintergrundsystem übermittelt werden.
Logs werden vom SDK an den aufrufenden Client gegeben
Platform
Afo
Beschreibung
Bemerkung
O.Plat_1
Für die Nutzung der Anwendung SOLL das Endgerät über einen aktivierten Geräteschutz (Passwort, Mustersperre, o. ä.) verfügen. Im Fall eines nicht aktivierten Geräteschutzes MUSS der Hersteller den Nutzer über die damit verbundenen Risiken aufklären.
O.Plat_2
Die Anwendung DARF Berechtigungen, die für die Erfüllung ihres primären Zwecks nicht notwendig sind, NICHT einfordern.
O.Plat_3
Die Anwendung MUSS den Nutzer auf den Zweck der anzufragenden Berechtigungen und auf die Auswirkungen hinweisen, die eintreten, falls der Nutzer diese nicht gewährt.
O.Plat_4
Die Anwendung DARF KEINE sensiblen Daten in Meldungen oder Benachrichtigungen, die nicht vom Benutzer explizit eingeschaltet wurden (siehe O.Plat_5), schreiben.
O.Plat_5
Die Anwendung KANN dem Nutzer die Optionen bieten, Meldungen und Benachrichtigungen, ggf. auch mit sensiblen Daten, anzuzeigen. Bei Werkseinstellung MUSS diese deaktiviert sein.
O.Plat_6
Die Anwendung MUSS Zugriffsbeschränkungen auf sensible Daten realisieren.
O.Plat_7
Die plattformspezifischen Mechanismen zu Interprozesskommunikation DÜRFEN NICHT zum Austausch von sensiblen Daten genutzt werden, sofern sie nicht zur Erfüllung des primären Zwecks der Anwendung erforderlich sind
O.Plat_8
Verwendet die Anwendung für die Erfüllung ihres primären Zwecks eine Rendering Engine, MUSS sie diese so konfigurieren, dass aktive Inhalte nicht ausgeführt werden. Falls aktive Inhalte für die Realisierung der Anwendung unabdingbar sind, MUSS die Anwendung das Nachladen von Inhalten auf Quellen beschränken, die unter der Kontrolle des Herstellers sind oder durch den Hersteller autorisiert wurden.
O.Plat_9
Wechselt die Anwendung in den Hintergrundbetrieb, MUSS diese alle sensiblen Daten aus der aktuellen Ansicht („Views“ in iOS bzw. „Activities“ in Android) entfernen.
O.Plat_10
Die Anwendung MUSS alle nicht benötigten Protokoll-Handler in Rendering-Engines deaktivieren.
O.Plat_11
Die Anwendung MUSS vor dem ordnungsgemäßen Beenden das Löschen aller anwendungsspezifischen Sitzungsdaten (bspw. Cookies) bei der genutzten Rendering Engine anfordern
O.Plat_12
Die Anwendung SOLL nach Beenden alle nutzerspezifischen Daten im Arbeitsspeicher sicher überschrieben haben.
O.Plat_13
Der Nutzer MUSS über Sicherheitsmaßnahmen informiert werden, sofern diese durch den Nutzer umsetzbar sind.
O.Plat_14
Ein abgebrochener Start SOLL als Sicherheitsereignis protokolliert werden. Die Protokollierung SOLL im Hintergrundsystem stattfinden
O.Resi_1
Die Anwendung MUSS dem Nutzer barrierearme Best-Practice-Empfehlungen zum sicheren Umgang mit der Anwendung und ihrer Konfiguration bereitstellen.
Code
Afo
Beschreibung
Bemerkung
O.Source_7
Die Anwendung MUSS sicherstellen, dass alle sensiblen Daten unverzüglich nach der Erfüllung ihres Verarbeitungszwecks sicher gelöscht werden.
Das ZETA SDK schreibt keine persistenten Daten
O.Source_4
Potenzielle Ausnahmen im Programmablauf (Exceptions) MÜSSEN abgefangen, kontrolliert behandelt und dokumentiert werden. Technische Fehlerbeschreibungen (z.B. Stack Traces) DÜRFEN dem Nutzer NICHT angezeigt werden.
Durch den Client sicherzustellen
Resilience
Afo
Beschreibung
Bemerkung
O.Resi_1
Die Anwendung MUSS dem Nutzer barrierearme Best-Practice-Empfehlungen zum sicheren Umgang mit der Anwendung und ihrer Konfiguration bereitstellen.
O.Resi_7
Die Anwendung SOLL Härtungsmaßnahmen, wie etwa eine Integritätsprüfung vor jeder Verarbeitung sensibler Daten innerhalb des Programmablaufs, realisieren.
O.Arch_6
Die Anwendung MUSS die Überprüfung der Integrität durch eine digitale Signatur ermöglichen. Die Authentizität der Anwendung ist durch die Vertrauenswürdigkeit der Bezugsquelle (s. A.Source) sichergestellt.
z.B. durch Nutzung der Hersteller-App-Stores und entsprechenden Authentizitäts-nachweis
O.Arch_9
Der Hersteller MUSS dem Nutzer eine barrierearme Möglichkeit bereitstellen, um Sicherheitsprobleme zu melden. Die Kommunikation SOLL über einen verschlüsselten Kanal stattfinden.
O.Arch_10
Die Anwendung SOLL beim Start auf verfügbare sicherheitsrelevante Updates prüfen. Wenn ein sicherheitsrelevantes Update verfügbar ist, DARF die Anwendung sensible Daten NICHT mehr verarbeiten, ohne dieses Update einzuspielen. Der Nutzer MUSS über die Möglichkeit eines Updates und über ein durchgeführtes Update informiert werden.
O.Arch_11
Der Hersteller MUSS für die Veröffentlichung der Anwendung (und ihrer Updates) eine Quelle wählen, auf der die Anwendung gegen Manipulation durch Unbefugte geschützt ist und die einen vertrauenswürdigen Kanal zum Bezug der Anwendung zur Verfügung stellt.
z.B. durch Nutzung der Hersteller-App-Stores und entsprechenden Authentizitäts-nachweis
O.Arch_12
Der Hersteller MUSS dem App-Nutzer einfach und sicher zugängliche Wege zum Bezug der Anwendung bereitstellen (z.B. in Form einer Link-Liste auf seiner Website, als individuell zugestellter QR-Code, o. Ä.).
O.Data_1
Die Werkseinstellung der Anwendung MUSS die maximale Sicherheit bieten.
Das SDK muss entsprechend durch den Client konfiguriert werden.
O.Resi_1
Die Anwendung MUSS dem Nutzer barrierearme Best-Practice-Empfehlungen zum sicheren Umgang mit der Anwendung und ihrer Konfiguration bereitstellen.
O.Resi_7
Die Anwendung SOLL Härtungsmaßnahmen, wie etwa eine Integritätsprüfung vor jeder Verarbeitung sensibler Daten innerhalb des Programmablaufs, realisieren.
Privacy
Afo
Beschreibung
Bemerkung
O.Arch_4
Keine unverschlüsselten sensiblen Daten in Backups.
O.Data_2
Die Anwendung MUSS sensible Daten verschlüsselt speichern. Die betriebssystemeigene Verschlüsselung des Dateisystems genügt nicht. Das Schlüsselmaterial für diese Verschlüsselung DARF NICHT unverschlüsselt persistiert werden. Dies gilt sowohl für flüchtiges Ablegen (z. B. im Arbeitsspeicher), als auch für dauerhaftes Speichern (z. B. in einer Cloud-Umgebung). Eine hardwareunterstützte Schlüsselverwaltung der Plattform SOLL bevorzugt verwendet werden.
Sichere Speicherung ist vom SDK an den Client delegiert.
O.Data_3
Die Anwendung SOLL sensible Daten in einem vor Einsicht und Manipulation besonders geschützten Bereich ablegen.
Sichere Speicherung ist vom SDK an den Client delegiert.
O.Data_4
Die Anwendung DARF Ressourcen, die einen Zugriff auf sensible Daten ermöglichen, gegenüber Dritten NICHT verfügbar machen.
Sichere Speicherung ist vom SDK an den Client delegiert.
O.TrdP_6
Die Anwendung SOLL sensible Daten nicht an Drittanbieter-Software weitergeben.
Für alle Aufrufe durch das SDK findet eine Authentifizierung nach gematik-Spezifikationen statt, so dass nur zugelassene Software verwendet wird (z.B. für IDP oder Ressource-Server). Andere Einbindungen sind durch den Client-Hersteller abzusichern.