[REQ:gemSpec_IDP_Frontend:A_19938-01#1] We support the smartcard idp. [REQ:gemSpec_IDP_Frontend:A_20529-01#1] We support the smartcard idp. [REQ:gemSpec_IDP_Frontend:A_20602#1] Authorization-Header setup of HTTP requests is done via interceptor pattern for every request. [REQ:gemSpec_IDP_Frontend:A_20606#1] TLS is enforced by the platform for every HTTP connection. Certain domains can be excluded from this rule by listing them in a dedicated NSAppTransportSecurity exception list. This list is empty for our application. [REQ:gemSpec_IDP_Frontend:A_20625#1] These checks are part of the DefaultIDPSession as part for the response parsing. If they fail, an error will be thrown. [REQ:gemSpec_Krypt:A_17207] BrainpoolP256r1 parameter spec is used for creating/verifying key for signature usage; exception: Biometric use case uses secp256r1 (This is considered in its respective specification.) [REQ:gemSpec_Krypt:A_17359] Not applicable, since there is no exchange of CAdES-encoded documents signed by a ECC key in our system. Generally the created signatures adhere to A_17207 if not stated otherwise in the respective specifications. [REQ:gemSpec_IDP_Frontend:A_20607,A_20609,A_20618] no exceptions set in NSAppTransportSecurity, HTTP via TLS is enforced; OS will use system root certificates in combination with set pinned certificates. see also: Requirements for Connecting Using ATS [REQ:gemSpec_Krypt:A_17322,A_17124,A_21275,A_21332-02,GS-A_4359,A_21275−01] TLS is enforced by the platform for every HTTP connection. Certain domains can be excluded from this rule by listing them in a dedicated NSAppTransportSecurity exception list. This list is empty for our application, see also: Requirements for Connecting Using ATS [REQ:gemSpec_Krypt:A_21222#1] The TrustStoreSession protocol and the implementation DefaultTrustStoreSession provide interfaces for validating certificates. Validity of the IDP Certificates is always checked, as the discovery document is only available as a stream, and each access will trigger a validity check. FD Certificates [REQ:gemSpec_Krypt:GS-A_4367#1,GS-A_4368#1] We use the platform provided secure random generator. iOS is FIPS 140-2 certified. The operating system uses an entropy pool with different sources, including a true random number generator from the secure enclave, that is present on every device. Security certifcates can be found https://support.apple.com/de-li/guide/certifications/apc3fa917cb49/web, including FIPS 140-2 und Common Criteria. [REQ:gemSpec_eRp_FdV:A_20032-01] Note: grace period for OCSP responses is 12h [REQ:gemSpec_Krypt:A_21218] Note: grace period for OCSP responses is 12h [REQ:gemSpec_eRp_FdV:A_19188] session data (ACCESS_TOKEN, ID_TOKEN, SSO_TOKEN, CAN) is saved in the keychain. Its deletion is managed by the OS. The key chain is sandboxed and can only be shared with other apps by the same vendor when explicitly set. All other mentioned data is deleted. [REQ:gemSpec_eRp_FdV:A_19229-01#1] Audit events will be deleted when the referencing task is deleted. Cascading relationship “task -> audit event” is defined in Sources/eRpLocalStorage/Prescriptions/ErxTask.xcdatamodeld/ErxTask.xcdatamodel/contents [REQ:gemSpec_IDP_Frontend:A_20741] Configuration within app-configuration.json, organizational process as in A_20603 [REQ:gemSpec_Krypt:A_17205] The app does not use the TSL. All TSL related parts are handled within the eRp-FD. [REQ:gemSpec_Krypt:A_17775,GS−A_5339] We cannot interfere with cipher suite lists, see Requirements for Connecting Using ATS for actual order. [REQ:gemSpec_Krypt:GS−A_5035,A_19215,A_20607] We use https only, see DefaultHTTPClient.swift. ATS forbids other connections. [REQ:gemSpec_Krypt:GS−A_5322] There is no API to control the session length, developer forums suggest it is 10 minutes for iOS. [REQ:gemSpec_Krypt:GS−A_5526,GS−A_5542] We use the recommended NSURLSession for best network security Preventing insecure network connections [REQ:gemSpec_eRp_FdV:A_19983] All used services except our analytics framework are permitted and attested by the Gematik and under the TI monitoring. The usage of our analytics framework is not under our control, but we exclusively send data to it and receive none. [REQ:gemSpec_eRp_FdV:A_19982#1] The agreement to the use of the analytics framework can be revoked. But other agreements cannot be revoked, since the app would not operate properly. [REQ:gemSpec_eRp_FdV:A_19981] The user is informed and required to accept this information via the data protection statement. Related data and services are listed in sections 5. [REQ:gemSpec_eRp_FdV:A_19980#1] The user is informed and required to accept this information via the data protection statement. Related data and services are listed in sections 5. [REQ:gemSpec_eRp_FdV:A_19979] We use external services: The Apothekenverzeichnis and our analytics framework. During the communication with the pharmacy, there will be data shared via a prescription code. The requirement to this feature is described in gemSpec_eRp_FdV sectin 5.2.3.10 and 5.2.3.11. Our analytics framework does not use medical personal data, see DSFA section 5.6 Verarbeitungsvorgang 4: Rezepte einlösen [REQ:gemSpec_eRp_FdV:A_19176#1] Authenticity is provided by the appstore and app signing. We choose secure options where possible as the default value. Where the user can choose options, we inform by presenting additional information (e.g. “storing” the login). [REQ:gemSpec_eRp_FdV:A_19089-01#1,A_19090-01#1,A_19091-01#1,A_19092-01#1] We do not link user session of multiple app starts, we forcefully regenerate a new user-id. Nevertheless the following still applies: Opt-In for Analytics will be asked while the app onboarding runs. After the onboarding ran, the user may change the analytics settings in the settings menu. [REQ:gemSpec_eRp_FdV:A_19096-01#1,A_19097-01#1] We do not link user session of multiple app starts, we forcefully regenerate a new user-id. Nevertheless the following still applies. [REQ:gemSpec_eRp_FdV:A_19178] Is covered by our MSTG. [REQ:gemSpec_eRp_FdV:A_19179#1] Annotation in code [REQ:gemSpec_eRp_FdV:A_19181-01] There is an opt-in option for analytics. Full app functionality is available also without opting in. The user’s choice is requested during onboarding and the user can opt-in and opt-out of analytics at any time. There are no further configuration choices. After successful authentication via health card the corresponding prescriptions, protocol data and messages are displayed. [REQ:gemSpec_eRp_FdV:A_24525#1] Whether analytics are enabled or not is persisted using UserDefaults. As these usere Defaults are empty upon installation, any call to bool(for:) will return to false. Opt-In for Analytics will be asked while the app onboarding runs. [REQ:gemSpec_eRp_FdV:A_19182] In order to minimize the risk of unknown vulnerabilities in dependencies, we use different measures: We develop according to Security by Design Principles (see E-Rezept-App - SSDLC.pdf - Section Richtlinien, Vorgaben und Best Practices). We train our engineers focussing on secure design and coding best practices (see Sicherheitsschulungen.pdf). We publish our Code on Github and use a bug bounty program (https://www.gematik.de/datensicherheit -> Coordinated Vulnerability Disclosure Program) [REQ:gemSpec_eRp_FdV:A_19185] Communication with the Fachdienst is protocoled via Audit Events. The user can revise them in the Settings menu (Profile Settings). [REQ:gemSpec_IDP_Frontend:A_21324#1] Token-key and code-verifier are encoded into an JSON object. [REQ:gemSpec_IDP_Frontend:A_21325#1] AccessToken is encyrpted for each network request to the Fachdienst via VAUClient module. [REQ:gemSpec_IDP_Frontend:A_21326#1] ACCESS_TOKEN information is managed by IDPToken structure. See O.Plat_12 regarding secure deletion. [REQ:gemSpec_IDP_Frontend:A_21327#1] ID_TOKEN information is managed by IDPToken structure. See O.Plat_12 regarding secure deletion. [REQ:gemSpec_IDP_Frontend:A_21328#1] Keychain storage encrypts session tokens. [REQ:gemSpec_IDP_Frontend:A_20525] Not applicable as authenticator module is within FdV, not 3rd party app [REQ:gemSpec_IDP_Frontend:A_20527] Not directly applicable as authenticator module is within FdV, not 3rd party app. AUTHORIZATION_CODE will be used directly. [REQ:gemSpec_IDP_Frontend:A_20499] Not applicable as authenticator module is within FdV, not 3rd party app. [REQ:gemSpec_IDP_Frontend:A_20525] Not applicable as authenticator module is within FdV. Consent is given by using the app. [REQ:gemSpec_IDP_Frontend:A_21578] iOS only allows Biometric access via secure enclave or higher order apis. [REQ:gemSpec_IDP_Frontend:A_21583] Secure Enclave is enforced with code attributes. [REQ:gemSpec_IDP_Frontend:A_21584] There is no API to allow or disallow an biometric authentication, iOS is handling the authorization process while using the private key for any cryptographic operation. [REQ:gemSpec_IDP_Frontend:A_21585] Default behavior for all apps when using private access group (https://developer.apple.com/documentation/security/keychain_services/keychain_items/sharing_access_to_keychain_items_among_a_collection_of_apps) [REQ:gemSpec_IDP_Frontend:A_21586] iOS will delete all user related data after user-account reset. Key-Chain data is not being synced with iCloud since kSecAttrSynchronizable is not applied
[REQ:gemSpec_IDP_Frontend:A_21590] References of SecureEnclaveSignatureProvider is limited to registration and altVerify usage. [REQ:gemSpec_IDP_Frontend:A_20608-01,A_20609,A_20618,A_20068-01]: Implemented by not deactivating ATS within Info.plist, path: NSAppTransportSecurity. [REQ:gemSpec_eRp_FdV:A_20033,A_19739] For TLS certificates, this is implemented by not deactivating ATS within Info.plist, path: NSAppTransportSecurity. For TI Certificates, this is implemented within the TrustStore module. [REQ:gemSpec_eRp_FdV:A_19086,A_19087#1] Tracking is only implemented for the purpose of Usability-Tracking. Sessions are not persisted, session ids are recreated each app startup. [REQ:gemSpec_eRp_FdV:A_19093-01#1,A_19094-01#1] Usage Tracking is called very sparse and boils down to one place where all visited screens are recorded. See usage of @Dependency(\.tracker) for all cases where the actual analytics framework is used. [REQ:gemSpec_eRp_FdV:A_20193,A_20194,A_20202] Camera is only used for scanning recipes and avatar setup. CoreLocation is used for pharmacy search. Usage is requested before actual first usage, the user is asked for permission. This is also enforced by the OS. [REQ:gemSpec_eRp_FdV:A_22778-01#1] Encryption of message to the Pharmacy is done with/for all provided certificates/recipients. [REQ:gemSpec_eRp_FdV:A_22779-01#1] Encrypted message is of form of a PKCS#7 container (CMS) [REQ:gemSpec_eRp_FdV:A_20181-01#1] Screen that presents the DataMatrix code for redeeming a prescription only contains some static texts and the image of the code. [REQ:gemSpec_IDP_Frontend:A_22302-01#1] As of now idp_sek_2 can only be true, as the false case is no longer allowed. Thus only the true case is implemented in the following code places. [REQ:gemSpec_eRp_FdV:A_20182] No advertisement or similar is presented in the app. Assigning a prescription to an pharmacy in only possible via the app’s pharmacy search. Pharmacy search results are only based on search term and filter criteria set by the user. [REQ:gemSpec_eRp_FdV:A_24579] See snapshot test (e.g. ‘testPharmacySearch_searchResultSuccess.iPhone8-light.png’) or the actual app to verify. [REQ:gemSpec_eRp_FdV:A_19183#1] We have no implementation of any sharing mechanism of FD data.

[REQ:BSI-eRp-ePA:O.Purp_1#1] The purpose is displayed as part of the Onboarding and can later be viewed from the settings. [REQ:BSI-eRp-ePA:O.Purp_3#1] Terms of Use acceptance is required as part of the Onboarding. [REQ:BSI-eRp-ePA:O.Purp_6#2] As most of the user decisions are client side no history is available. Only the current state can be inspected. [REQ:BSI-eRp-ePA:O.Purp_7#1] Most libraries are self written and cover only what is needed. Dependencies are only included if really necessary. We think about including only sub packages, but as most dependencies are very small, this is hardly used. Besides that, no means of removing unused dependency functionality is available for libraries of the platform. [REQ:BSI-eRp-ePA:O.Purp_8#1] Sharing of data is only for the primary purpose of the application e.g. sending presriptions to a pharmacy or sharing a prescription with a family member. We do not store data in shared containers in any way. [REQ:gemSpec_eRp_FdV:A_19183#1] See O.Purp_8 for usages. [REQ:BSI-eRp-ePA:O.Purp_9#1] Sensitive data is only shown for the purpose of this application. This includes display of prescriptions, personal data and health data.

[REQ:BSI-eRp-ePA:O.Arch_1#1] See external SSDLC documentation. [REQ:BSI-eRp-ePA:O.Arch_2#1] See external Data and Security concept. [REQ:BSI-eRp-ePA:O.Arch_3#1] All cryptography is specified by gemSpec_Krypt in corporation with BSI [REQ:BSI-eRp-ePA:O.Arch_4#1] All data is either stored encrypted within the keychain or excluded from system backup, which also excludes files from cloud backup. [REQ:BSI-eRp-ePA:O.Arch_5#1] CAN and PIN verification is not done within the application but on the eGK chip. Actual authentication by confirming the eGK signature and validating the eGK certificate is done by the IDP. Authorization of users is done by the FD by validating the Access-Token signature. For Input-Validation and Escaping please see O.Source_1 and O.Source_2. [REQ:BSI-eRp-ePA:O.Arch_6#1] Apple already implements this with a signed binary delivered to customers. An altered application can only run on a jailbroken device. If a user is using a jailbroken device, may it be known or unknown, we display a security alert so a user can make an informed decision to use or not use the application. [REQ:BSI-eRp-ePA:O.Arch_7#1] See Source/eRpApp/Resources/en.lproj/FOSS.html for library usage purposes. We use Swift as our programming language. We do not use reflections for calling a businesslogic. That’s why we can be sure, that library code (that we do not use) cannot be executed. [REQ:BSI-eRp-ePA:O.Arch_9#1] Link within DataPrivacy.html to https://www.gematik.de/datensicherheit [REQ:BSI-eRp-ePA:O.Arch_10#1] Implemented via APIKey usage against APOVZD and FD. All requests against the backends may respond with an 403 status code. The App stays usable, but only without any server connection. The user is informed, that an update is required. [REQ:BSI-eRp-ePA:O.Arch_11#1] Sole source for the app is the official Apple AppStore. Apple provides a secure ecosystem for downloading applications that incorporate signing and verification of the application. The app is only available in the AppStore and not in any other store. [REQ:BSI-eRp-ePA:O.Arch_12#1] Not applicable as we are only using the official Apple AppStore.

[REQ:BSI-eRp-ePA:O.Source_1#1] We have two potential unknown inputs, one being the scanner, that scanns QR Codes or Data Matrix Codes. External interactions are managed through Universal Linking, with thorough validation of URL parameters to ensure only predefined variables are accepted. [REQ:BSI-eRp-ePA:O.Source_2#1] Data escaping is managed by the operating system frameworks. We do not create SQL queries manually; instead, we utilize CoreData as an ORM. Queries are constructed using NSFetchRequests and NSPredicates, which automatically escape all manual input. Additionally, actual user data is transmitted via FHIR, with the escaping process handled by Apple’s provided FHIR library. [REQ:BSI-eRp-ePA:O.Source_2#8] See all files named ModelsR4.Bundles+<TypeName> within eRpRemoteStorage Package to find all references for FD related FHIR parsing. All other files within the Module are either helpers or provide support for creating FHIR objects that may be sent to the FD. [REQ:BSI-eRp-ePA:O.Source_3#1] Error messages are localized using the Foundation.LocalizedError protocol. Search for LocalizedError to see all instances. Most errors are localized with static text, some errors contain server side error messages. User data is never used for error messages. Logging is only active on debug builds. See O.Plat_4 for reference. [REQ:BSI-eRp-ePA:O.Source_4#1] Exception handling in swift uses Errors to represent the exception. We use a custom protocol CodedError that is autogenerated for all error messages. Together with LocalizedError we create error messages that contain a user readable description as well as some technical identifiers to easily identify specific error scenarios and give better support. See CodedError.swift and CodedError.generated.swift for the protocol and the autogenerated implementations of it. [REQ:BSI-eRp-ePA:O.Source_5#1] As exceptions and errors are kind of the same construct in swift, this aspect is hard to answer. If a server responds with 401/403 we delete tokens or other security measures, because they are no longer valid anyways. While logging in via biometrics we create temporary data containers for the user certificate and key identifier, that are deleted if the process is not completed properly and kept if the process completes. [REQ:BSI-eRp-ePA:O.Source_6#1] Swift uses Automatic Reference Counting that does not require active memory management. Raw memory access is possible but only used for swift-OpenSSL dependency that wraps the c library. [REQ:BSI-eRp-ePA:O.Source_7#1] All sensitive data is handled via value types. After usage the swift runtime handles deletion of the in memory representation. There is no method known to securely overwrite value types. Security is ensured by operating system and process boundaries. Secure enclave encryption keys can never leave the secure enclave by design. [REQ:BSI-eRp-ePA:O.Source_8#1] We use swift macros to remove development code. Configuration of server Environments is done within AppConfiguration.swift. A debug menu is available within settings, rooted within SettingsView.swift. UI-Test Scenarios are placed within the application, but exclude for production builds. [REQ:BSI-eRp-ePA:O.Source_9#1] We use common defaults for all compiler security related settings. See Xcode build configuration for eRpApp Target using current Xcode for actual settings. [REQ:BSI-eRp-ePA:O.Source_10#1] We use an external SAST and SCA tool that is run at least on every release build. See Jenkinsfile_SAST for technical details. There is additional integration into our merge-reqeuest tooling.

[REQ:BSI-eRp-ePA:O.TrdP_1#1] Dependencies are handled with SPM. A technical description of all dependencies can be found within dependencies.yml. In the future, a generated SBOM will replace the Package.resolved for this purpose. [REQ:BSI-eRp-ePA:O.TrdP_2#1] Dependencies are updated regulary by an organizational process. Any dependency security issues raised by automatic checking are handled immediately. A list of all compiled dependencies can be found within dependencies.yml. [REQ:BSI-eRp-ePA:O.TrdP_3#1] SCA Scans are part of our release pipeline, see O.Source_10. [REQ:BSI-eRp-ePA:O.TrdP_4#1] Library updates are done by a manual periodic process. If any security issues arise and no fix is expected to be provided, a manual fork of external libraries is implemented. In our documentation, we define a bug bar and a grace period depending on the criticality of the vulnerability. Our bug bar is set to “Low”, see scripts/sast, lines including severity-threshold=low. [REQ:BSI-eRp-ePA:O.TrdP_5#1] Actual dependencies can be found within eRp-App.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved, containing pinned versions with corresponding hashes. Library updates always require manual interaction to update the *.resolved files. We use very few providers of libraries and try to avoid any unnecessary dependency. Each providing party/dependency is evaluated by looking at GitHub metrics like open issues, stars and activity in general. [REQ:BSI-eRp-ePA:O.TrdP_6#1] We do not share sensitive data with third parties. See data usages within O.Purp_8 and O.Arch_2. [REQ:gemSpec_eRp_FdV:A_19979#1] We do not share sensitive data with third parties. See data usages within O.Purp_8 and O.Arch_2. [REQ:BSI-eRp-ePA:O.TrdP_7#1] See O.Source_1 and O.Arch_5. [REQ:gemSpec_eRp_FdV:A_19182#1] See O.Source_1 for input/output validation. [REQ:BSI-eRp-ePA:O.TrdP_8#1] As most libraries are source code dependencies, these scans are part of SAST Scanning. Libraries that are not source code dependencies are the precompiled OpenSSL and OpenHealthCardKit (own library but different repository). All third party libraries are mirrored into internal repositories. If necessary we fork libraries to apply fixes.

[REQ:BSI-eRp-ePA:O.Cryp_1#1] We use API-Keys for FD and APOVZD communication for legal reasons, not for security reasons. Besides that, private keys for encryption are either created and stored within the secure enclave or stored within the eGK. As encryption for Server communication is done ephemeral via ECDH-ES, no static private keys on client side are necessary. Usages of encryption include the following code pieces. [REQ:BSI-eRp-ePA:O.Cryp_2#1] All cryptographic requirements are defined within gemSpec_Krypt. The document was created together with BSI. [REQ:BSI-eRp-ePA:O.Cryp_3#1] All cryptographic requirements are defined within gemSpec_Krypt. The document was created together with BSI. [REQ:BSI-eRp-ePA:O.Cryp_4#1] All cryptographic requirements are defined within gemSpec_Krypt. The document was created together with BSI. [REQ:BSI-eRp-ePA:O.Cryp_5#1] We use Brainpool256R1 and ECSECPrimeRandom 256, see usages in O.Cryp_1 to O.Cryp_4 [REQ:BSI-eRp-ePA:O.Cryp_6#1] Persisted cryptographic keys are created within the devices secure enclave. Temporal keys are discarded as soon as usage is no longer needed. [REQ:BSI-eRp-ePA:O.Cryp_7#1] As Brainpool256R1 is not available within secure enclave but enforced by BSI where possible, we use secure enclave encryption only for biometric authentication. Everywhere else, cryptographic operations are ephemeral or use the eGK as a secure execution environment.

[REQ:BSI-eRp-ePA:O.Rand_1#1] We use the platform provided secure random generator. iOS is FIPS 140-2 certified. The operating system uses an entropy pool with different sources, including a true random number generator from the secure enclave, that is present on every device. Security certifcates can be found https://support.apple.com/de-li/guide/certifications/apc3fa917cb49/web, including FIPS 140-2 und Common Criteria.

[REQ:BSI-eRp-ePA:O.Auth_1#1] Our authentication concept is described in the following repository: https://github.com/gematik/api-erp/blob/master/docs/authentisieren.adoc. Roles in the scope of the IDP are defined in https://gemspec.gematik.de/docs/gemSpec/gemSpec_IDP_Dienst/latest/#3.1. As stated in O.Auth_14, we have no mechanism to invalidate tokens. [REQ:BSI-eRp-ePA:O.Auth_2#1] There is no client side separation of authentication and authorization. [REQ:BSI-eRp-ePA:O.Auth_3#1] One way to connect to the FD is to login by using the eGK. For that login, the physical card, as well as knowledge of the PIN is required. Login via gID (Gesundheits ID) is described in O.Auth_4. [REQ:BSI-eRp-ePA:O.Auth_4#1] Authentication via gID (Gesundheits ID) is possible. To do that an inter-app flow is used that opens the insurance company app on the users device, and after successfull authentication there, jumps back into the E-Rezept-App. [REQ:BSI-eRp-ePA:O.Auth_5#1] If the registered biometric features get changed (within system settings), private keys for alternate authentication are deleted. For privacy reasons, neither the FD nor the application gather or store user data that is not crutial, e.g. the current WiFi. [REQ:BSI-eRp-ePA:O.Auth_6#1] We increment a counter whenever the application is opened and an attempt to unlock the application fails. If the counter is greater than 0, the user is informed about that in a hint on the password/unlock screen. For remote logins, an Audit Log for every FD access is available in each user profile. [REQ:gemSpec_eRp_FdV:A_19177#1] An Audit Log for every FD access is available in each user profile. [REQ:BSI-eRp-ePA:O.Auth_7#1] There are no passwords to guess for server login within our application. Only eGK login is directly available within the application. The users application password is not delayed, as any user with Device-PIN access would have access to the unencrypted file system as well. [REQ:BSI-eRp-ePA:O.Auth_8#1] The SceneDelegate exchanges the active window with an authentication window, every time the app gains focus. [REQ:BSI-eRp-ePA:O.Auth_9#1] A Timer is used to measure the time a user is inactive. Every user interaction resets the timer. [REQ:BSI-eRp-ePA:O.Auth_10#1] Token invalidation happens after 12 hours. If a user is still active, a re-authentication via eGK, Biometrics or Insurance App is necessary. Each meaning the possession and or knowledge of the needed user input. [REQ:gemSpec_eRp_FdV:A_20185#1] Token invalidation happens after 12 hours as the IDP provied SSO-Token is no longer valid after that time. [REQ:BSI-eRp-ePA:O.Auth_11#1] Authentication via eGK cannot be altered, as the physical card cannot be modified without authentication (e.g. PIN change). See gemSpec_COS for details. Adding a authentication key that is secured via biometrics (labeled as “save login” within the card wall) enforces a new authentication via eGK on server side. There is no other way to change existing login “credentials”, as there is no “password”. [REQ:BSI-eRp-ePA:O.Auth_12#1] We use TI Certificate Pinning and a Trust Store for VAU communication. See TrustStore and VAU Module for implementation. [REQ:BSI-eRp-ePA:O.Auth_13#1] Session tokens and related data are stored within the keychain. We embrace a protocol specifically made for storing data that needs to be secured. [REQ:BSI-eRp-ePA:O.Auth_14#1,O.Auth_15#1] Our Authentication Tokens cannot be invalidated effectivley as they are stateless and no server stores active/valid tokens anywhere. Invalidating Authentication Tokens in our context means deleting them on client side. The client side invalidation can thus be done by manual logout or profile deletion. Logout is accessible within the Settings -> Specific User Profile -> Logout.

[REQ:BSI-eRp-ePA:O.Pass_1#1,O.Pass_2#1] We use zxcvbn-ios as a password strength indicator and enforcer for the application password. [REQ:BSI-eRp-ePA:O.Pass_3#1] The user may change the app passwords within the settings. [REQ:BSI-eRp-ePA:O.Pass_4#1] The application password is not used for the baackend. There is no protocol for the application password within the application, although we implement a counter for failed password attempts. [REQ:BSI-eRp-ePA:O.Pass_5#1] We use the keychain to persist the hashed app password and the corresponding salt. The salt is regenerated, whenever a new password is stored.

[REQ:BSI-eRp-ePA:O.Data_1#1] User preferences are asked without discrimination within the onboarding process. Application permissions are asked, whenever they are needed, e.g. location permission is only asked when the user is about to search for a pharmacy (see O.Plat_2). If a user chooses to not give the permission, features are still available, if possible. [REQ:BSI-eRp-ePA:O.Data_2#1] We use the OS Keychain to persist sensitive data. The keychain either stores or encrypts via SecureEnclave. Encrypting the database has disadvanteges that we discussed and decided to not yet implement additional database encryption. We are periodically evaluating solutions for this requirement. [REQ:BSI-eRp-ePA:O.Data_3#1] Currently it is not possible to store data within the secure enclave on iOS. We store all data on the encrypted application container on the device. See eRpApp.entitlements for NSFileProtectionCompleteUnlessOpen usage. [REQ:BSI-eRp-ePA:O.Data_4#1] Everything we store, safe or send anywhere is both verified as in O.Resi_6 and or encrypted, such as Keychain or the application container. [REQ:BSI-eRp-ePA:O.Data_5#1] Ephemeral private keys are released as soon as they are no longer needed (see O.Source_5). [REQ:BSI-eRp-ePA:O.Data_6#1] Collected data is sparse and use case related as required. [REQ:BSI-eRp-ePA:O.Data_7#1] Private data is not initially created by the application. Only additional information, such as redeeming or deleting prescriptions create data. The created data is kept on the FD. [REQ:BSI-eRp-ePA:O.Data_8#1] The device camera is used optional for scanning prescriptions and for setting a profile avatar. Avatar image data never leaves the device. [REQ:BSI-eRp-ePA:O.Data_9#1] The device camera is used for scanning prescriptions and for setting a profile avatar. Neither use-cases export data to the device photo library or export in any other way. [REQ:BSI-eRp-ePA:O.Data_10#1] Password fields are marked as such and thus disallow autocorrections. Search for SecureField or SecureFieldWithReveal for all usages. [REQ:BSI-eRp-ePA:O.Data_11#1] We use default platform behavior for password fields. Pasting into password fields is allowed, copying is denied. In general the clipboard is only filled with any data, if the user triggers it. [REQ:BSI-eRp-ePA:O.Data_12#1] There is no API from Apple that allows extraction of biometric or private key data from the secure enclave. Non ephemeral keys are only created within the secure enclave. [REQ:BSI-eRp-ePA:O.Data_13#1] Suppressing Screenshots is not possible as of now. [REQ:BSI-eRp-ePA:O.Data_14#1] See eRpApp.entitlements for NSFileProtectionCompleteUnlessOpen usage. [REQ:BSI-eRp-ePA:O.Data_15#1] Biometric keys are always bound to the device and cannot leave the secure enclave. Actual user data is excluded from backups and cannot be exported. [REQ:BSI-eRp-ePA:O.Data_16#1,O.Data_17#1] Deletion is completely handled by the OS. We have no means of doing anything while deinstallation is running. All sensitive keychain data is tied to the user profile id and cannot be accessed after deinstallation. though technically the information still persists for a short period of time (<24h) after some kind of daily cleanup routine by the OS it will be removed. The user may choose to manually logout or delete profiles before app deletion. [REQ:BSI-eRp-ePA:O.Data_18#1] Not applicable: no kill switch realized.

[REQ:BSI-eRp-ePA:O.Paid_1#1] The app does not offer any purchases. The only paid service, that is used by the app in some extent can be mobile data. The terms of use in the app states, that costs might occur using mobile data. [REQ:BSI-eRp-ePA:O.Paid_2#1,O.Paid_3#1,O.Paid_4#1,O.Paid_5#1,O.Paid_6#1,O.Paid_7#1,O.Paid_8#1,O.Paid_9#1,O.Paid_10#1] The app does not offer any purchases.

[REQ:BSI-eRp-ePA:O.Ntwk_1#1] No exceptions set in NSAppTransportSecurity, HTTP via TLS is enforced (see also: Requirements for Connecting Using ATS); Certificate transparency ensures authenticity of the server side. User access tokens ensures client side authenticity. [REQ:BSI-eRp-ePA:O.Ntwk_2#1] We use one wrapper around NSURLSession for network communication that uses an ephemeral configuration only allowing TLS 1.2 or greater. Network communication security in general is specified within gemSpec_Krypt and aggreed upon with BSI. [REQ:BSI-eRp-ePA:O.Ntwk_3#1] We use the system provided NSURLSession for network communication and no additional layer for TLS encryption. The iOS encryption is certified according to https://support.apple.com/de-de/guide/certifications/apc3fa917cb49/web [REQ:BSI-eRp-ePA:O.Ntwk_4#1] We do not pin TLS Certificates, instead we pin TI PKI Certificates for FD and IDP communication. Since we got an agreement with the BSI regarding the usage of pinning, (TI PKI Pinning is enough) we remove the TLS pinning itself, in favor of certificate transparency + our second layer of TI Certificate pinning. If accessing the APOVZD, we don’t have such pinning. However, the need for pinning is due to high protection demand of the medical data. But the APOVZD does not hold such data, thus we interpret that pinning is not necessary there at all. Furthermore, we don’t see attack vectors regarding the APOVZD. It only required an API Key, but no authentication. Redeeming prescriptions directly with pharmacies, we encrypt the payload with an encryption certificate, that again is checked to be within TI PKI. [REQ:BSI-eRp-ePA:O.Ntwk_5#1] We use NSURLSession as the base for all our network requests. NSURLSession uses ATS (App Transport Security) that enforces rules for TLS Certificates, such as authenticity. See https://support.apple.com/en-us/103214 and https://developer.apple.com/documentation/bundleresources/information_property_list/nsrequirescertificatetransparency# for additional information. [REQ:BSI-eRp-ePA:O.Ntwk_6#1] The server uses extended validation certificates to ensure maximum authenticity. On top of TLS we also implement message authenticity by validating checksums and signatures. For IDP Communication see O.Resi_6, for FD communication see the following code. [REQ:BSI-eRp-ePA:O.Ntwk_7#1] The system enforces ATS App Transport Security since the app uses the standard URL Loading System URLSession which automatically negotiate the most secure connection available from the server. Also there are no exceptions configured in the eRpApp/Resources/Info.plist thus insecure networt connections are disabled by default. [REQ:BSI-eRp-ePA:O.Ntwk_8#1] Logging does not take place in the FdV for reasons of data minimization. Furthermore, it is not entirely clear who this log would be for. We have separate responsibilities divided between two different operators of the IDP and the specialized service, and gematik as the manufacturer of the e-prescription app. None of the backend systems have such a required endpoint. Moreover, the aforementioned questions would still arise.

[REQ:BSI-eRp-ePA:O.Plat_1#1] We test for device pincode at startup and show a dialog if no pin is set. [REQ:BSI-eRp-ePA:O.Plat_2#1] The app ony configures entitlements that are used for it’s primary purpose. All configured entitlements are configured in eRpApp/Resources/Info.plist and in eRpApp/Resources/eRpApp.entitlements. [REQ:BSI-eRp-ePA:O.Plat_3#1] The platform enforces dialogs whenever accessing private data or sensors and user permission is not already given. Localizations can be found within InfoPlist.strings [REQ:BSI-eRp-ePA:O.Plat_4#1] We never show sensitive data as all errors are localized with custom descriptions (See LocalizedError implementations). Some errors have localized parameters such as a failed PIN counter. Some errors are sent from the server, these messages show only generic information what went wrong. See O.Source_3 for reference. [REQ:BSI-eRp-ePA:O.Plat_5#1] Not applicable: displaying of messages not realized. [REQ:BSI-eRp-ePA:O.Plat_6#1] Implemented by the OS Sandboxing. [REQ:BSI-eRp-ePA:O.Plat_7#1] The only method we use for inter process communication is universal linking. Current outgoing use-cases are limited to login with insurance company apps. No sensitive data is transferred, the actual payload is decided by the server, as the universal links are created server side. [REQ:BSI-eRp-ePA:O.Plat_8#1] We only use native code and do not rely on any rendering engine, besides rendering some static HTML Pages (e.g. OSS-Licenses, Data Privacy, Terms of Use) that do not contain any scripts. [REQ:BSI-eRp-ePA:O.Plat_9#1] The content window is blurred upon leaving the application to not expose content to the system multitasking switcher. [REQ:BSI-eRp-ePA:O.Plat_10#1] Implemented using a WKWebViewDelegate. [REQ:BSI-eRp-ePA:O.Plat_11#1] WebViews only display local content that is delivered together with the application. Javascript is disabled, linking and loading other content is disabled. All other links to websites open the system browser. No cookies are created within the application or any webview that the application hosts. [REQ:BSI-eRp-ePA:O.Plat_12#1] The app’s memory is subject to the operating system’s memory and therefore it has no control over the used memory. There is no technique known to overwrite memory in swift in a safe way, so that value types are deleted safely. The platform promises safety at process boundaries. [REQ:BSI-eRp-ePA:O.Plat_13#1] During the onboarding process the user is forced to secure the access to the app either via a biometric trait or a strong password (or both). There is no additional security setting the user cannot set within the onbording. [REQ:BSI-eRp-ePA:O.Plat_14#1] We do not log within the application. Though, logging is in place on FD and IDP and user data related events are logged into the audit events, that can be displayed within the application.

[REQ:BSI-eRp-ePA:O.Resi_1#1] The onboarding contains defaults that are best practices, such as using biometrics for authentication. While using the Cardwall, selecting the “save login” option results in an dialog with additional information, to let the user make informed decisions. A missing device passcode results in a dialog that is recommending the setup of a device passcode. [REQ:gemSpec_eRp_FdV:A_19181-01#1] The onboarding contains defaults that are best practices, such as using biometrics for authentication. While using the Cardwall, selecting the “save login” option results in an dialog with additional information, to let the user make informed decisions. A missing device passcode results in a dialog that is recommending the setup of a device passcode. [REQ:BSI-eRp-ePA:O.Resi_2#1] Jailbreak detection is done on startup of the application after the app authentication. If a jailbreak is detected, a information dialog is presented to the user. [REQ:BSI-eRp-ePA:O.Resi_3#1] Starting within a debug environment is only possible on rooted/jailbroken devices. If that is the case, the user sees a dialog and can choose to continue or cancel using the application. See O.Resi_2 for jailbreak detection details. [REQ:BSI-eRp-ePA:O.Resi_4#1] Starting with unusal app rights is only possible on rooted/jailbroken devices. If that is the case, the user sees a dialog and can choose to continue or cancel using the application. See O.Resi_2 for jailbreak detection details. [REQ:BSI-eRp-ePA:O.Resi_5#1] Device Integrity may only be compromised on jailbroken devices. If that is the case, the user sees a dialog and can choose to continue or cancel using the application. See O.Resi_2 for jailbreak detection details. We exclude very old and unsecure devices, by restricting the application to modern iOS Versions. That restriction is automatically restricting the range of devices it can run on. See options.deploymentTarget.iOS path within project.yml or the generated IPHONEOS_DEPLOYMENT_TARGET within the project.pbxproj file for the iOS Version restriction. [REQ:BSI-eRp-ePA:O.Resi_6#1] IDP Communication is secured by using TLS with pinned Certificates as well as JWEs with keys that are pinned using a TI specific trust anchor as well as OCSP. FD Communication is secured by using TLS and VAU encryption, again with pinned Certificates for both methods. APOVZD communication uses TLS with pinned certificates. The Pinned certificates fingerprints can be found within Sources/eRpApp/Resources/Info.plist. [REQ:BSI-eRp-ePA:O.Resi_7#1] Recent Jailbreaks force a reboot or restart of springboard. Thus the application will also be restarted in these cases. The check for hardening is done on app startup and should be sufficient. [REQ:BSI-eRp-ePA:O.Resi_8#1] The application source is available on github. Any measure of preventing reverse engineering would be pointless. [REQ:BSI-eRp-ePA:O.Resi_9#1] Data is not stored while moving between platforms or devices. Private keys are stored within the secure enclave an cannot leave the device. Downgrades are prohibited by the operating system and update mechanisms. [REQ:BSI-eRp-ePA:O.Resi_10#1] Missing internet connection or other means of disruption use the same error mechanisms as every part of the app uses for normal errors. Data is only deleted where appropriate, e.g. invalid tokens are deleted. User Data is not deleted unless explicitly confirmed by the user.