Security Requirements for Bank iD Protection in Mobile Applications

Version: 1.0 modified on 09.04.2025

Mobile applications are currently becoming a key point for digital identity and the management of users’ personal and sensitive data. In the area of Bank iD – that is, verified electronic identity – it is essential to ensure a level of protection that minimizes the risks of unauthorized access and misuse.

Every mobile application must include security measures corresponding to the risks it faces depending on its focus and the data it processes. This includes protection against cyberattacks, unauthorized manipulation, loss or compromise of sensitive information. However, in the area of banking identity, security requirements are particularly strict, because Bank iD ensures verified electronic identity for users.

Therefore, the following requirements and recommendations focus specifically on the area of banking identity protection (Bank iD), based on OWASP MAS https://mas.owasp.org/ i.e. MASVS (Mobile Application Security Verification Standard) and practical testing procedures according to MASTG (Mobile Application Security Testing Guide), which service providers and mobile application developers should implement and verify.

This area focuses on the proper handling of sensitive data and its protection against unauthorized access, especially when stored in local storage.

Mandatory requirements

Minimization of sensitive data storage

• The application should limit the persistent storage of user login credentials and other sensitive data (e.g. Bank iD tokens) only to the necessary duration.
• Justify why specific data is being stored and whether it is not possible to keep it only in RAM memory after use.
• Logs must not contain personal data (PII) or other sensitive information (e.g. login credentials, tokens). If data needs to be logged for debugging purposes, there should be a mechanism for its anonymization or removal in the production build process.

Use of secure storage

• Access tokens should be stored in protected storage, e.g. Android KeyStore (ideally through EncryptedSharedPreferences with keys generated in TEE) and iOS Keychain (using Secure Enclave, if available).
• It is not advisable to store sensitive data in general configuration, clipboard or shared storage (e.g. in files accessible to other applications).

Prohibition of storing sensitive data in unsecured parts of the system

• Authentication tokens or other highly sensitive data should not be stored in logs, unencrypted SharedPreferences or in the cache.
• When working with temporary files, it is advisable to use platform tools for encryption (e.g. EncryptedFile on Android) and securely delete them immediately after use (so-called secure delete) to prevent leakage through temporary storage.

Recommended requirements

Encryption of authentication tokens in memory (RAM)

• It is advisable to use enclave/keystore mechanisms (e.g. Secure Enclave on iOS) so that tokens are in RAM as little as possible and only in encrypted form, if it makes technical sense (e.g. in cases where tokens are not often needed and can be securely loaded only for each transaction).
• For highly sensitive operations, temporary cryptographic keys (so-called ephemeral keys) can also be used, which minimize the time the key is in memory.

Integrity validation of local data files

• If the application works with a local database or files, it should implement integrity checks (e.g. hashing, signing, MAC – Message Authentication Code) to detect unauthorized changes or manipulation.
• In cases where high security is required, encrypting the entire local database (e.g. SQLCipher for SQLite) and periodic validation of checksums can also be considered.

The aim of this group is to ensure that all cryptographic operations (encryption, hashing, key generation) are performed in accordance with best practices and that the application remains secure even in the context of possible future attacks, e.g. quantum computers.

Mandatory requirements

Proper generation and management of cryptographic keys

• Keys must be generated in a secure environment, e.g. iOS Keychain / Android Keystore, and must not leave the protected space (e.g. TEE – Trusted Execution Environment).
• For each key, there must be a clearly defined purpose (e.g. only for encryption, only for signing, only for authentication) and corresponding restrictions (e.g. limiting key export).

Allowed algorithms

Encryption:

• AES-256 in authenticated modes (GCM, CCM) or ChaCha20-Poly1305.
• ECC (e.g. secp256r1, Curve25519, secp384r1) for asymmetric encryption and key exchange.
• RSA-3072+ (prefer ECC for better performance and shorter keys).

Hashing:

• SHA-256, SHA-3 (e.g. SHA3-256, SHA3-512) or SHA-512.

Key Derivation Function (KDF):

• Argon2id with a minimum of 3 iterations and allocation of 64 MB of memory (however, it is recommended to choose parameters according to the performance capabilities of the device).
• PBKDF2 with a minimum of 600,000 iterations when using HMAC-SHA256, or 210,000 iterations when using HMAC-SHA512 (it is necessary to consider the performance of target devices and the risk of offline attacks).

For all key derivation, it is also essential to use a sufficiently long and random salt.

Forbidden algorithms:

• DES, 3DES, MD5, SHA-1, RC4, AES-ECB, CBC without HMAC (resp. without using a secure authentication mode – Encrypt-then-MAC), RSA < 2048 bits.

These algorithms are considered outdated or cryptographically weak and therefore must not be used in current applications.

Recommended requirements

Rotation of long-lived keys

• Keys that are used long-term (e.g. for Bank iD, static cipher or signature) should be rotated regularly. This will prevent mass breaches in case of key compromise and increase resistance to long-term attacks. To ensure the currency and validity of keys, we strongly recommend regularly fetching the current set of public keys from the JWKS (JSON Web Key Set) address provided by Bank iD. This mechanism allows for automatic retrieval and updating of keys without the need for manual intervention, thereby increasing the security and reliability of the system.

Proper handling of cryptographic libraries

• It is advisable to use only verified and updated libraries (e.g. OpenSSL, BoringSSL, native platform libraries).
• Avoid implementing cryptographic functions yourself (especially low-level ones), as this often leads to errors and vulnerabilities.

Asymmetric algorithms and post-quantum cryptography

• Shor's algorithm can (in a fully functional quantum computer) break classical asymmetric schemes (RSA, ECC). Therefore, it is recommended to monitor and gradually implement post-quantum (PQ) algorithms, e.g. CRYSTALS-Kyber, CRYSTALS-Dilithium, Falcon, SPHINCS+.
• For a gradual transition, a hybrid mode is often chosen (e.g. a combination of ECDH + Kyber), which maintains backward compatibility with the existing infrastructure while partially increasing resistance to future quantum attacks.

The area dealing with user verification, user session management and defense against attacks on login mechanisms.

In the context of Bank iD or other sensitive services, it is particularly important to ensure secure authentication implementation, minimize the risks of token theft or replay and protect the user session.

Mandatory requirements

External browser for web authentication

Service Provider MUST use:

• External browser:
  • On iOS: SFSafariViewController (Safari View Controller) or ASWebAuthenticationSession (recommended for OAuth/OpenID Connect).
  • On Android: Chrome Custom Tabs.
  • Drop-in alternatives: E.g. ASWebAuthenticationSession (iOS) for integrated solutions.

Secure login flows and protection against replay

• Authentication flows must be transmitted only over TLS 1.3) with Forward Secrecy and secure TLS configuration.
• It is necessary to implement protection against token replay attacks using nonce.

Proper session termination

• Upon logout, the application must remove all authentication tokens from secure storage (e.g. Keychain, Keystore) and ensure their invalidation on the server as well (so-called remote logout). This minimizes the risk of an attacker reusing a valid token. It is important that the service provider (Service Provider) initiates the session termination through the Bank iD interface, because without this notification, Bank iD will not know to terminate the session.

Proper session policy settings

• For sensitive operations (e.g. use of authentication or authorization), a short session validity period should be set or re-authentication should be required. This minimizes the risk of unauthorized access in case of user inactivity. It is important that the service provider (Service Provider) implements an appropriate session management policy in accordance with Bank iD security standards.
• When changing a password or other authentication credentials, existing sessions (resp. all existing tokens) need to be invalidated.

When using refresh tokens, it is important to pay attention to their security, especially given their long validity, which can be up to one year. Due to this long lifespan, it is crucial to implement measures to protect against their theft. One of the most effective ways is to bind the refresh token to a specific user device. This ensures that even if an unauthorized person obtains the token, they will not be able to use it on another device. Refresh token rotation is another security measure, but without user consent, it is not possible to change its validity beyond the originally set period. Therefore, the emphasis on binding the token to the device is essential to minimize the risk of misuse.

Recommended requirements

Multi-factor authentication (MFA)

• The application should support TOTP (e.g. Google Authenticator, Authy), push notifications, biometric features (Face ID, Touch ID) or other additional factors to increase security.
• The use of FIDO2/WebAuthn mechanisms is also recommended if the platform and server-side support it.

Protection against automated attacks

• Rate limiting mechanisms should be implemented on the SeP API side to limit the number of attempts and detect brute-force and credential stuffing.
• In case of frequent attacks, CAPTCHA (or another equivalent test), IP blacklisting/graylisting or other protection tools (WAF – Web Application Firewall) can be deployed.

Prohibition of using WebView for web authentication

• Reasons: Sharing cookies with the application, risk of phishing (missing URL bar), possibility of JavaScript injections (token manipulation).

Focuses on protecting data in transit and the proper implementation of TLS, including defense against MITM attacks.

Mandatory requirements

Encrypted communication

• All transmissions must take place over TLS 1.3 with Forward Secrecy (e.g. using ECDHE), which increases protection against subsequent decryption of stored communication (so-called Perfect Forward Secrecy).

Secure TLS configuration

• The application must reject outdated protocols (SSL, TLS 1.0/1.1) and untrusted certificates.
• HSTS (HTTP Strict Transport Security) on the server side is an important protection against so-called downgrade attacks or unwanted switching to insecure HTTP.

Recommended requirements

Protection against downgrade attacks

• On the client side, verify that the application does not accept older protocols when establishing a TLS connection, not even as a fallback.

This section deals with how the application works with native system interfaces, other applications and how it uses sandboxing.

Mandatory requirements

Compromised device detection

• The application should detect root/jailbreak (depending on platform capabilities) and limit or block critical functions if detected.
• Detection can be done, for example, by checking for typical signs of jailbreak (Cydia, rewritten libraries, unofficial repositories on iOS) or su/sudo binaries on Android.
• Warning: 100% reliable root/jailbreak detection does not exist, so it is necessary to combine multiple methods and design risky functions so that they are as difficult to exploit as possible even if protection is bypassed.

Limiting interactions with other applications

• Sharing sensitive data (URL schemes, clipboard) should be minimized. The clipboard can be read very easily by another application, so it should not be used for transferring login credentials.
• If the application provides its own URL scheme, it is necessary to verify the origin of the call (deeplinking) and prevent URL hijacking attacks.

Recommended requirements

Protection against screen recording attacks

• The application could detect screen recording when sensitive data is displayed and block it (if the platform supports it). For example, FLAG_SECURE can be used on Android, and limited APIs are available on iOS for detecting mirroring.
• This is mainly about reducing the risk of login credential theft via screen recordings or screenshots.

Permissions management

• The application should request only the necessary permissions that are required for functions related to Bank iD (e.g. camera for QR code only if it actually needs to scan the code).
• Unused permissions should be removed and it is advisable to require explicit user consent (runtime permissions) to prevent unwanted granting of sensitive access.

Secure use of WebView

If WebView is still necessary in the application (e.g. for displaying certain content elements, but not for the main login flow), the application should:

• Disable or significantly limit JavaScript if it is not really needed.
• Avoid addJavascriptInterface() (on Android) or condition it with careful security checks.
• Validate loaded URLs – it is recommended to set a custom WebViewClient and check if the domain or path is on a list of trusted ones.
• Prevent mixed content so that unencrypted (HTTP) resources are not loaded.
• Clear WebView data (cache, cookies) after logout to prevent sensitive data leakage.
• On iOS, use WKWebView instead of the outdated UIWebView, which is insufficient from a security perspective.

This minimizes the risks associated with potential XSS attacks, sensitive data leakage and other threats typical for unsecured WebView implementations.

This area deals with secure development practices, version management, updates and code maintenance. The goal is to ensure that the final production application does not contain unnecessary or risky elements (debug tools, testing backdoors, hardcoded keys) and is able to respond quickly to newly discovered vulnerabilities.

Mandatory requirements

Clean build and no sensitive information in code

• The production build must not contain debug tools or sensitive information (API keys, passwords) in a freely readable form (e.g. directly in the text of the source code, unprotected in strings.xml, etc.).
• Use build variants (e.g. debug vs. release) and apply proguard/r8 or other obfuscation methods for release builds to make access to sensitive information more difficult.

Regular security updates

• There must be a process for the rapid deployment of security patches – i.e. the ability to release a new version of the application without a long approval process (so-called fast patch release).
• Libraries and frameworks (e.g. cryptographic libraries, network layer, OAuth/OIDC libraries) should be continuously updated with regard to newly identified vulnerabilities.

Penetration tests and audit

• The application should be regularly reviewed by an independent penetration test and security audit.

Recommended requirements

Automated scanning and testing (CI/CD)

• Tools for static (SAST) and dynamic (DAST) security analysis should be integrated into the development cycle (CI/CD) to catch potential problems (e.g. hardcoded keys, incorrect API usage) as early as possible.
• It is also recommended to involve software composition analysis (SCA), which checks library versions and warns about known vulnerabilities in dependencies.

The goal is to make it harder for attackers to exploit the application, eavesdrop, hook and otherwise manipulate the runtime environment. This category is particularly important in the context of Bank iD, where unauthorized modification of the application or eavesdropping on sensitive functions can lead to a significant security threat.

Mandatory requirements

Protection against debugger and hooking tools

• The application should detect and block attempts to attach a debugger or hooking frameworks (e.g. Frida, Xposed, Cydia Substrate) to critical functions.
• This can be achieved through various detection methods (e.g. checking the signature of dynamic libraries, detecting the presence of debug processes, etc.). However, it is necessary to expect that 100% protection cannot be achieved – the goal is to increase the difficulty of the attack.

Application integrity check

• The application should regularly verify its own integrity (e.g. signature, hash checks) to detect unauthorized changes in the code or in the running process.
• In practice, this can involve examining the hashes of the .apk/.ipa package, verifying the code signature and checking whether the code has been patched (tampering detection).

Recommended requirements

Code obfuscation

• It is advisable to use obfuscation tools (ProGuard, R8, DexGuard, Swift obfuscation) to make reverse engineering more difficult.
• Obfuscation does not guarantee 100% protection, but it significantly increases the difficulty of code analysis by an attacker.

Runtime Application Self-Protection (RASP)

• For critical operations, RASP techniques can be used, which actively detect and prevent code manipulation at runtime.
• RASP solutions can monitor anomalies in memory, attempts at hooking and other suspicious events and react, for example, by terminating the critical operation or notifying the server.

This chapter focuses on the protection of privacy and personal data, including compliance with legislation (e.g. GDPR).

Mandatory requirements

Minimization of personal data collection and processing

• The application should collect only the data that is necessary for the use of Bank iD and related functions.
• Avoid "over-collecting" – do not use identifiers or tracking codes that are not necessary for the functionality of the application.

Transparent user information

• The user must be clearly informed about what data is collected, for what purpose and with whom it is shared (e.g. in the context of Bank iD intermediation).
• There must be a possibility to withdraw consent to processing (if this does not prevent basic functionality). This should also include an explanation of how this will affect the operation of the application.

Recommended requirements

Anonymization and pseudonymization

• Sensitive data should be stored and transmitted in anonymized or pseudonymized form whenever possible (e.g. hashed user IDs, tokens instead of real identifiers).
• This reduces the risk that a potential data breach (or eavesdropping) will lead to the identification of specific users.

Explicit data retention policy

• Rules should be defined and published on how long and under what conditions personal data is stored and when it is deleted (data retention policy).
• Allow users to request deletion (right to be forgotten) in accordance with legislation and ensure that the relevant data is truly deleted from all systems.

• Follow the mandatory requirements that minimize the most serious risks.
• Implement recommended practices to strengthen security in the context of constantly evolving threats.
• Consider specific platform mechanisms (Android KeyStore, EncryptedSharedPreferences, iOS Keychain and Secure Enclave) and their proper integration.
• Use an external browser or drop-in alternatives for authentication (e.g. Safari View Controller or Custom Tabs) and limit the role of WebView to only necessary scenarios without critical processes such as login.

By following this procedure, a high level of protection of sensitive data, user electronic identity (Bank iD) can be achieved, and the overall trustworthiness of the mobile application can be increased.