LUCA-LucaSecurityConcept-280121-1434-156

Dieses Dokument ist Teil der Anfrage „Unterlagen zur Prüfung der luca-App

/ 10
PDF herunterladen
Luca Security Concept Goal The Luca System is designed to enable anonymous and secure contact information transfer. Visitors and guests of public or private events should be able to anonymously share their contact data with the organizer. Only in case of an infection, shall the local health authorities be enabled to access the collected personal contact information. Both the consent of the infected guest and the organizer are required. The following data is processed during the identification of possible contact persons. Types of data contact details of guests                              check-in information of guests                      location information name                                                    location                                           name of the location street, street number, city, postal                     check-in time                                      name and email of the contact code                                                    check-out time                                     person of the location phone number                                                                                               address of the location email                                                                                                      coordinates of the location check-in radius private event tracing code health authority information name of the authority name, email, certificates of legitimate employees The personal information of guests is the most valuable asset processed in the Luca system. System Overview Component                   Description [external] Email           Is used to contact organizers and health departments, also to validate given contact information Service
1

[external]                     Is used to validate phone number used while entering contact details SMS Service [user] Guest                   A person that is required to securely provide their personal information before entering a location and later (on infection) submit their location history to the health department [user] Heath                   employee of the local health department responsible for identification of contact persons Department Employee [user] Location                private person, or business owner/manager of a location that has guests and is obliged to trace contact information Owner                          shall be able to manage events / locations and scan guests Guest App                      The Luca guest app, also described as Luca app, is the interface for the guests. (Android, App,                 Guests enter the contact information in the app and use the app to checkin at several locations without re-entering their Webapp)                        contact details. Health Department              Enables the health department to trace infection cases and contact potential contact persons. Frontend Location Frontend              The frontend of the managers/organizers of locations/venues/restaurants. Here, a professional or private user can create locations or events which will enable the manager to checkin guests Luca Backend                   Stores encrypted check-in and contact information (never in possession of personal information in plain text) Centrally orchestrates the other technical components Scanner Frontend /             The scanner app is used by the organizer or its employees to scan the anonymous Luca codes and check-in guests App Self-registration              The self-registration frontend enables locations to also let guests enter their information manually on-site on an iPad or Frontend                       something similar. Static Code                    Generates printable QR codes to be used by people without smartphones to allow check-ins at Luca locations Generator Core processes Luca's primary goal is to automate the identification of contact persons for venues, restaurants and locations and ease the health department's identification of possible contact persons of infected persons. The table below provides a high-level overview of the involved processes to achieve this goal. Process              Purpose                                         Involved parties         Input                     Output name Location           Register an event or a venue with the Luca       professional location   email, password,          venuePrivKey registration       system and enable it to check-in guests via      owner                   location information      venuePubKey Luca.                                            OR                      (name, address, ...) private event organizer                           Scanner Links Health             Collect the check-in history of infected users   Health department       authentication            Certified "health department encryption department         and trace/ potential contact persons from        manager                 certificate, name of the  key pair" (HDEKP) and "... signing key registration       those locations                                                          health department         pair" (HDSKP) User               Set up a smartphone user to check-in at          some citizen willing to personal contact details  userPrivKey registration       venues using Luca                                user Luca                                         userPubKey (via Luca                                                                                                             additional local secrets App)                                                                                                                  anonymous userID Static QR          Set up a static QR code badge allowing           Static Code Generator,                            anonymous QR Code code               check-in at venues to people without a           some citizen willing to generation         smartphone                                       use Luca User checkin       Transmit anonymous contact information to        Luca user, venue        anonymous QR Code         uploaded tracing data /out               location owner                                   owner (or employee) 1) Scanner checkin 2) self-registration 3) table checkin 4) self/automated checkout
2

Identification    Retrieve contact information in case of an      Health department       user TAN                  affected locations of                infection                                       employee, Luca user,    HDEKP                     contact data of affected users contact           1) Reveal contact information to health         venue owner persons           department (Infection)       2) Reveal location history to health department 3) Venue approval for identification of contact persons 4) Reveal contact information of possible contact persons Asymmetric Encryption The underlying security used during the core processes relies on our asymmetric encryption scheme that shall be presented in the following section. We define our asymmetric encryption similar to DLIES (BSI TR-02102-1 3.5) according to the technical guideline of the BSI . Components asymmetric key parameters                        secp256r1 (NIST P-256) symmetric encryption EK                          AES-128-CTR message authentication code MACKM                HMAC-SHA256 key derivation function H                        SHA256 Encryption                                                                          Decryption function signature: AsymEnc(data, publicKey, [iv])                                  The inputs for the decryption are encryptedData, receiverPrivateKey, IV, ephemeralPublicKey and an (optional) MAC The inputs for encryption are data and a receiverPublicKey. The encryption procedure: The decryption procedure: 1. generate ephemeral ECC keyPair: ephemeralPrivateKey and ephemeralPublicKey                                                             1. calculate DHKey = ECDH(receiverPrivateKey, 2. generate IV = random bytes (16 bytes) (if not given as input)                      ephemeralPublicKey) 3. calculate DHKey = ECDH(ephemeralPrivateKey,                                     2. calculate encryptionKey = SHA256(DHKey || 0x01) (truncate to receiverPublicKey)                                                                16 bytes) 4. calculate encryptionKey = SHA256(DHKey || 0x01) (truncate to                    3. calculate authenticationKey = SHA256(DHKey || 0x02) 16 bytes)                                                                      4. verify MAC (if available) = HMAC-SHA256(encryptedData, 5. calculate authenticationKey = SHA256(DHKey || 0x02)                                authenticationKey) 6. calculate encryptedData with AES-128-CTR(data,                                  5. calculate decryptedData = AES-128-CTR(encryptedData, encryptionKey, IV)                                                                encryptionKey, IV) 7. calculate MAC = HMAC-SHA256(encryptedData, authenticationKey)                                                       Output: decryptedData Output: encrypted data, MAC, IV, ephemeralPublicKey Notes: the MAC might be skipped/ignored and the IV might be given as an input Processes Daily Public Key Rotation Luca uses a daily key rotation system to reduce the impact of a any single compromised key. The keys are identified by a keyId (integer), which is incremented with each rotation. The rotation will be triggered by any health department employee that logins after the last daily public key expired. The daily public key is owned and kept secret by the health authorities. It is used to encrypt the user's personal data on checkins and registration, as described in the following processes. Rotation Process The life time of a daily key pair is 24 hours. If a daily public key has expired, any one health department employee automatically generates a new dailyLucaKeyPair. The newly generated daily private key is then shared with all other health departments by encrypting it for each HealthDepartmentEncryptionPublicKey and uploading it to the luca system. This effectively replaces the old daily key. Measures are taken to solve race conditions if multiple health department employees try to rotate the daily public key simultaneously. Stepwise process health department employee logins via client certificate
3

check for current expiration of daily key pair; continue only if key is expired locally generate a new daily key pair (NIST P-256) fetch all HealthDepartmentEncryptionPublicKeys (in the form of encryption certificates) from the luca system validate each encryption certificate against the configured CA and check their revocation status via OCSP encrypt dailyPrivateKey with all HealthDepartmentEncryptionPublicKeys and upload the encryptedDailyPrivateKeys sign the dailyPublicKey, the ID of the signing health department and the current timestamp with the local HealthDepartmentSigningPrivateKey upload the signed dailyPublicKey to luca system luca system validates the utilized HealthDepartmentSigningPrivateKey against the configured CA and checks its revocation status via OCSP luca system validates the signature of the uploaded dailyPublicKey, checks the signed timestamp for plausibility and concludes the rotation process result: daily key pair is exchanged, all new operations will be performed using the new key pair Key Destruction Daily private keys that are older than roughly two weeks (epidemiologically relevant time span) can be destroyed as no infection-relevant contacts happen beyond this time. The luca system can delete all such encryptedDailyPrivateKeys for all health departments. Furthermore, the health department frontend app might need to remove locally stored copies of such daily private keys. User registration 1) App Registration Upon first launch the user provides their contact information (see on top) to the app. The app then verifies the user's phone number via the luca system. For that, the plaintext phone number is sent to the backend, forw arded to the SMS service that creates a challenge. The SMS service sends a verificationTAN as SMS or voice call to the provided phone number. After entering the verificationTAN in the Luca app, it is verified via the backend with the SMS service provider. After that, the user's phone number is no longer stored on the luca backend. The app generates an EC secp256r1 keypair, a user tracing secret (16 bytes entropy), a user verification secret (16 bytes entropy) and a userDataKey (16 bytes random data). The app then encrypts the personal information and the user verification secret using AES-CTR- 128 with the userDataKey and signs it with the user's private key. The user's publicKey, the encrypted data and signature are transferred to the luca system which returns a unique userID for the app to store. The App stores the following: user id (uuid) user public key (ec secp256r1) user private key (ec secp256r1) user data key (16 bytes random data) user tracing secret (16 bytes random data) user verification secret (16 bytes random data) The Luca system stores the following: user id                                                                  User Registration.txt user public key encrypted personal information (including verificationSecret) encrypted data iv 2) Static QR Code Generation The static QR code generation workflow is meant to be usable by users without access to a smartphone. The user will register through a purchase onboarding process. The generated code will then be printed and sent to the user via postal service. This process is subject of active discussion. See here for more details. These static QR codes cannot give the same security and privacy guarantees as the app-based checkin, though. Location Registration Both professional location owners and private event organisers can register with the luca system via a web application. The registration process involves the generation of a venueKeyPair whose private key is then stored either locally or encrypted by a password in the luca system. 1) Professional Location Owner A professional location owner (e.g. concert venue, museum, restaurant, etc.) can register a long-term location in the luca system. Each location can be managed by a web interface to set up individual QR code scanners and configure other venue-specific parameters (e.g. auto checkout behaviour). Process
4

location owner registers with email and password locally generate a venue key pair (NIST P-256) in the web application store the venuePrivKey to local file system upload the venuePubKey to the luca system 2) Private Event A private event is a one-time event organised by an individual user that is identified via its email address. Private organiser may be contacted by the health department for identification of contact persons similarly to professional venue owners. For simplicity we don't require private users to download and keep the private key for their event locally. Instead, they are asked to provide a password that is used to encrypt the locally generated private key. In case identification of contact persons becomes necessary, they can retrieve their encrypted private key from the luca system and decrypt it with their event password. Process create a one-time event by providing a valid email address via a web interface generate a venueKeyPair (NIST P-256) provide a sufficiently strong password for the event derive encryption and authentication keys from the password using PBKDF2 encrypt venuePrivKey like: AES-128-CTR(venuePrivKey, encKey, IV) authenticate the encryptedVenuePrivKey via HMAC-SHA256 under authKey upload encryptedVenuePrivKey, PBKDF2-salt, IV, venuePubKey and MAC to the luca system Health Department (HD) Registration A new health department receives an authentication certificate to authenticate to Luca. This certificate does not need to be signed by the external CA, as it only needs to be trusted by Luca. It is used to login to the Luca frontend. The health department creates an encryption certificate (HealthDepartmentEncryptionKeyPair HDEKP) and a signing certificate (HealthDepartmentSigningKeyPair HDSKP) on first login. Both of these certificates must be issued by the external CA via a manual process to ensure authenticity of the requesting HD admin. They are used to authenticate to (a) the app on checkins and (b) other health departments on key rotation /distribution. HDEKP is the key pair that needs to be accessible by any HD employee when performing Identification of contact persons, as it decrypts the daily health department private key. The HDSKP is highly sensitive, as it authenticates the daily health department public key. The signed public key of the HDEKP is uploaded to the Luca system, where it is available when distributing a new daily key. Both keypairs' private keys are securely stored locally. For use cases where the keypairs need to be accessible from multiple workstations the HD frontend provides secure export and import functionalities. Future Improvement: Employee Management Tools In a future version the HD frontend will provide facilities to simplify distributing access to the keypairs among health department employees. To this end, the HDEKP will be stored encrypted on the Luca backend. Each administrator and employee will receive an Offline Keypair that can be used to access the HDEKP. This will avoid the process of exporting and importing copies of the HDEKP and make it easier to revoke access for specific employees' keypairs, when needed. Overview of secrets and their location of the health department Secret                                         Use                                                                         Location HDEKP                                         Public Key: Encrypt the daily health department key (one per HD)           Public Key: Luca backend HealthDepartmentEncryptionKeyPair             Private Key: Decrypt the daily health department key                       Private Key: Local devices HDSKP                                         Sign the daily health department key for key rotation in the morning       Admin local device HealthDepartmentSigningKeyPair Admin Auth Cert                               Authenticate to Luca System to manage employees                            Admin local device Employee Auth Cert                            Authenticate to Luca to trigger identification of possible contact persons Employee local device (Planned) Admin Offline Key Pair              Decrypt the HDEKP                                                          Admin local device (Planned) Employee Offline Key Pair           Decrypt the HDEKP (transport HDEKP from Admin to Employee)                 Employee local device User Check-in/out In this process the Luca system creates and persists a trace object that can be used (a) to trace an infected user's check-in at a specific location, and (b) to trace potential contact persons, that were at the same location at the same point of time.
5

There are multiple possibilities how the check-in can be done. The basic use case is for a venue to use the Luca Scanner App to scan a QR code generated by the Luca Guest App. Alternatively, users can self-check-in using a printed QR code (for example at a restaurant table). In both cases the general flow of the process is the same: The Guest App generates a trace ID, that can be used to trace the user if and only if the tracing party (the heath department) know the user's tracing secret (see Identification of contact persons). Scanner Check-in When check-in is activated, the Guest App will continuously generate new traceIDs. Each trace created as HMAC-SHA256 of the user id and the current timestamp (down-sampled to the minute) as data and the user tracing secret as key. The resulting value is truncated to the first 16 bytes. Subsequently, the App asymmetrically encrypts the userID and the userDataKey for the current daily health department key. The IV is defined as the first 16 bytes of the ephemeral public key used in the encryption scheme. The App then calculates a verification tag as HMAC- SHA256 of the timestamp and the encrypted data as data and the user verification secret as key, truncated to the first 8 bytes. In this process, the App fetches the current dailyPublicKey along with its generation time stamp from the Luca backend. The dailyPublicKey and the timestamp are signed by a specific HealthDepartmentSigningKeyPair certificate so that the Luca App can verify the authenticity of the provided data. For that, the HDSKP- certificate must be downloaded, validated against the issuing CA and checked for its revocation status via OCSP. Only then will the Luca App       Scanner Check-in.txt trust the downloaded dailyPublicKey. Furthermore, the app checks the signed generation time stamp for plausibility and reject the usage of outdated dailyPublicKeys. The App then displays a QR code, updated every minute with the current timestamp and a new traceID. The QR code contains: QR code version device type keyID (specifies which daily health department key was used) timestamp traceID encrypted data (userDataKey and user id encrypted as described above) ephemeral public key verification tag checksum (SHA256 of all data above, truncated to 4 bytes) The payload is concatenated and encoded with ASCII85 to be displayed as a QR code. Upon scanning the QR code, the Scanner App in turn must asymmetrically encrypt the encrypted data and the verification tag using the venue public key. The IV is randomly generated. The Scanner App uploads the following data to the Luca backend: traceID scannerID timestamp (doubly) encrypted data IV, MAC, and ephemeral public key from the encryption device type (indicating the Scanner App) When storing this information the Luca backend associates it with the venueID (which it determines using the scannerID) and the check-in time. Self-Check-in In this variation the Guest App assumes the role of the Scanner App in order for the user to check-in at the venue autonomously. To enable this process, the venue needs to provide a QR code that encodes the required information: a valid scannerID for this venue, the venueID, and the venue public key used for the asymmetric encryption. The Guest App can use the scannerID in order to retrieve additional information about the venue from the Luca backend and display it to the user. Once the user scans the QR code using the Guest App, the App generates the same information as in the Scanner Check-in variation. Note that this involves the same validation of the dailyPublicKey signature as detailed above. Then, instead of displaying it as a QR code, it also performs the steps normally done by the Scanner App (i.e. add second encryption layer, associate with scannerID and device type) and uploads it to the Luca system.
6

Additional Data Luca provides the functionality to associate a check-in with additional data. This can be done by either the Guest App or by the Scanner App. Additional Data is designed to be non-sensitive data that can be used in the identification of possible contact persons. An example is the table number a user was placed at in a restaurant. Regardless of which App creates and uploads the additional data, the data is asymmetrically encrypted using the venue public key before being uploaded. Checkout When a user leaves a venue, they can be marked as checked out. This can be done (1) manually on the Guest App, (2) automatically by the Guest App, or (3) manually by the venue owner. In case of the automatic checkout the App can use the user's geo-coordinates in combination with the venues geo-coordinates and a geofencing radius. To perform the checkout the respective traceID to be checked out and the current timestamp are sent to the Luca backend. Security Considerations When encrypting the (encrypted) user data and the additional data with the venue public key the authenticity of that public key is crucial. In the Scanner Check-in scenario, this is guaranteed because the scanner app is already provisioned with the correct public key. In the Self Check-in scenario, users and the venue owners need to access the authenticity of printed QR codes, in order to avoid scanning forged QR codes that have been printed and placed at the venue by an attacker. The scannerID sent as part of the check-in data is the only indicator Luca can use in order to infer the associated venue. Forging a non-existent scannerID could potentially allow an attacker to send bogus data to the Luca system. However, this does not reveal any information to the attacker in any scenario. On a similar note, knowing the scannerID of a venue basically allows the impersonation of the venue's Scanner App. This is accepted; more specifically, this is specifically desired in the Self Check-in scenario. Notably, the physical equivalent of this would be for an attacker to "steal" the Self Check-in QR code and place it in another venue. The Luca system cannot avoid such mischief. Caused by the limited capacity of QR codes, the Guest App directly interacts with the Luca backend in the processes listed above. The Luca backend could associate the user's current IP address with the checked-in traceID, thus there is no storing of the associated IP addresses. In addition it is not possible to infer future or past traceIDs without having access to the user-owned traceSecret. Identification of contact persons The Identification of contact persons consists of two major parts: (1) tracing the location history of the known infected person and (2) finding and informing potential contact persons. Tracing the Location History of an Infected Person In the beginning of this process, an infected person is directly contacted by a local health department. The health department needs to acquire the secrets stored locally within that person's Guest App. Therefore, the health department will ask the person to reveal their personal information and location history via a functionality in the App. Step 1: Accessing the Infected User's Tracing Secret When this functionality is activated, the Guest App creates a User Transfer Object that holds the relevant information. The app will encrypt the secrets for sharing like follows: serialize userId, userDataKey and userTracingSecret in a JSON asymmetrically encrypt the serialized JSON for the current daily health department key Infection 20201122.txt upload the encryption results to Luca Luca will return a TAN The TAN serves as an identifier for the Transfer Object within Luca and does not carry any further security relevance. The Luca user can now communicate the TAN to the health department, in order for the health department to retrieve the encrypted package from Luca. In order to retrieve the encrypted Transfer Object from Luca the health department employee needs to login using their login certificate. To decrypt the encrypted Transfer Object, they further need access to the relevant daily health department keys, which they can retrieve from the Luca backend and decrypt using they HealthDepartmentEncryptionKeyPair. Step 2: Recovering the Infected User's Location History In this step, the health department finds all venues where the infected user has checked in within the relevant recent timespan (e.g. 14 days).
7

To start the tracing process, the health department sends the infected user's tracing secret to the Luca backend. Based on the secret and the affected userID, the backend will generate all possible traceIDs for the affected time frame. These traceIDs are used to find all trace objects checked in by the user. Luca can use the trace objects to contact all venues the infected user has attended. They will be contacted via Email and asked to reveal the potential contact persons. Step 3: Finding Potential Contact Persons The venue downloads all trace objects in the Location Frontend and validates which guests might be contact persons (for example using Additional Data attached to the trace objects). Both the Additional Data and the outer layer of encryption in the trace object can be decrypted using the Location's private key. The decrypted data is still encrypted with some daily health department key and thus is only accessible to the health departments. The encrypted data contains the userID and the userDataKey (see User Check-in). This data is then uploaded back to Luca in order to be shared with the health department. After each affected location responded, the health department can download and decrypt the traces using the relevant daily health department key. The health department now has access to the personal data of the contact persons. The authenticity of each trace can be validated using the verification secret. Security Properties User tracking It is impossible for the LUCA system to track users as they generate trace ids that can only be correlated when having the user trace secret, which will only be transmitted in an infection case and even then only readable for the health department. Users that only had contact with an infected user will not reveal their user trace secret and therefore can not be tracked. Data safety The users personal information is encrypted at all times and will only ever be readable by persons that have knowledge of the userDataKey. The userDataKey can only be obtained from the user himself or in an encrypted form from a venue that scanned his QR code. All decryption is handled locally by the respective actors. Data integrity All data stored in the luca system is in some way signed/mac'ed by the owner of the data, so no employee can alter data. Security Considerations Static Badges Badges with static content can be copied and misused. A future protection could be One-Time Badges or TAN lists with one-time use, so a QR code can only be used with a valid unused TAN. Data Analysis The LUCA system can potentially infer from the data how many users were at a venue at any given time. This could be mitigated by sending dummy checkins as noise to obfuscate the real usage. Checkin Data verification The LUCA system can not verify data integrity at certain levels. Example: The LUCA System can not verify that data was not modified by the venue. Th e venue can not verify that the provided data by the user is valid. A venue can submit arbitrary data as no verification is done by the LUCA system. But the data can and will be validated when the health department decrypts the users personal information and can then verify the authenticity and integrity of the data. Internet connection If we want to disallow venues uploading checkins for timestamps that are different to the current time, they will need to have constant internet connection while doing checkins. If we don't disallow this, they can upload checkins for scanned badges at arbitrary times as we have no way of verifying this (this only applies to badges not app users). Rogue Venues A rogue venue could invalidate users data or just not upload checkins. They could also loose, forget or destroy their venueKeyPair. Rogue User
8

A user can submit invalid data, which will only be detected at the decryption stage of the health department. This is mitigated by validating the phone number via SMS verification. A user can loose, forget or destroy his app and his secrets when infected. Rogue Service An employee can't alter data but they still can remove and invalidate data when having direct access to the database. Glossar Description                                                Owner / Who has access? authentication certificates                  X509 certificates used to login as an health department     employee himself employee healthDepartmentEncryptionKeyPair            Generated once for each health department on the first login of the admin healthDepartmentEncryptionPrivKey            used to decrypt the encryptedDailyPublicKey                 stored encrypted at luca, key is owned by every employee and the admin of the corresponding health department employeeKeyPair                              generated once on the first login of each health department employee employeePrivKey                              used to decrypt the healthDepartmentEncryptionKeyPair       stored encrypted at Luca, key is owned by Health Department and it's employees dailyPublicKey                               used to encrypt personal information and traces during      publicly stored at Luca the identification of contact persons encryptedDailyPrivateKey                     used to decrypt personal information and traces during      stored encrypted with the the identification of contact persons                       healthDepartmentEncryptionPublicKey for each healthDepartment tan / user tan                               human readable code, generated on upload of transfer        generated by App, given to Health object, transmitted via phone between guest and health      Department department employee traceId                                      derived ID of the checkin, obfuscated to only allow         publicly stored at Luca tracking on infection case userDataKey                                  randomly generated on user-side, used to encrypt            stored in App in secure key storage personal information encrypted in QR code stored encrypted (twice) at Luca on checkin userId                                       unique identifier of the user in the luca system, ex. used to identify personal information userKeyPair                                  generated on user registration userPrivKey                                  randomly generated store in guest app, used to sign         stored in App in secure key storage transfer objects userPubKey                                   public key of the user, uploaded to luca system on          publicly stored at Luca registration userTracingSecret                            randomly generated on user-side, used to secure tracing     stored in App in secure key storage information only given to healthDepartment when user infected userVerificationSecret                       used to authenticate information of the user, and to verify stored in App in secure key storage traces by the health department stored encrypted at Luca, key is the userDataKey venueKeyPair                                 generated pub/priv key pair owned by the location owner / venue; generated on registration of the location owner
9

venuePrivKey                               private key of the venue, generate on venue/location          stored encrypted at Luca, key is owned by registration                                                  venue operator a) downloaded by the location owner, and securely stored by the user                                            or b) (private events) for one-time events, generated on         stored locally at venue operator event registration, encrypted with 10-digit alphanumeric ; encrypted stored in the luca backend venuePubKey                                public key of venue, used on checkin to secure the            stored publicly at Luca check-in /trace information Used implementations of cryptographic operations function                 web/node             iOS                                                                           Android ecc keyPair generation indutny/elliptic     Apple native Security library with SecKeyCreateRandomKey                       Bouncy Castle ECDSA-SHA256           indutny/elliptic     Apple native Security library with ecdsaSignatureMessageX962SHA256 algorithm   Bouncy Castle ECDH                   indutny/elliptic     Apple native Security library with ecdhKeyExchangeStandard                     Bouncy Castle AES-128-CTR            digitalbazaar/forge  CryptoSwift                                                                    Bouncy Castle HMAC-SHA256            digitalbazaar/forge  CryptoSwift                                                                    Bouncy Castle SHA256                 digitalbazaar/forge  CryptoSwift                                                                    Android MessageDigest
10