Describe the bug

if a DCC is sent from smartphine device A to smartphone device B via NFC, it does not arrive directly in the wallet app on device B. The sent file ends up in the file system of Device B and must first be imported.

Expected behaviour

a DCC sent via NFC should be received directly in the WalletApp

Steps to reproduce the issue

1. select at device A a DCC and press "share pdf" or "Share image" button
2. sent the DCC to Device B
3. the DCC is not received by the walletApp

Technical details

WalletApp 1.2.8-tst (41) Xiaomi Mi Note 10 Lite

Testdata:

• Testrule: VR-DX-0004
• Date of test : 10.05.2022
• Birthdate of person: 18 years + 1 Day old (Birth Date = 09.05.2022) VAC-Certificate with above Birthdate gets evaluated by Verifier app correctly as "limited" while WalletApp brings a different result than Verifier, namely "valid".

Expected Behaviour: Both apps must bring the same result (this means, that wallet app should also say "limited")

Describe the bug

if you click the update button for the revocation state, no update is performed, at least the date and time are not updated

Expected behaviour

the date and time is updating, after you click the update button

Steps to reproduce the issue

1. open walletApp
2. go to settings
3. click the update button in the row "update revocation state"

Technical details

WalletApp 1.2.8-tst (41) Xiaomi Mi Note 10 Lite

Describe the bug

Revoked certificates get evaluated as valid.

Expected behaviour

Revoked certificates get evaluated as invalid.

Steps to reproduce the issue

1. Claim a revoked certificate;
2. Load the certificate;
3. Click check validity for chosen country and date, while the certificate is revoked;
4. App says: "Valid certificate".

Technical details

Galaxy XCover 4, Android 9, Wallet App Android, Version: 1.2.8-without-tan-request-tst (37)

Additional context

For about 1 second while loading the revoked certificate, one sees a red text saying "Revoked !" -- yet the text flashes out as soon as the certificate is loaded. (See attached video).

https://user-images.githubusercontent.com/76050122/155003670-834dfdd2-4242-4a44-ae1c-599a908b89c0.mp4

## Describe the bug

When I scan a QR Code at next step should be displayed the details informations of the certificate. Steps should be like in iOS wallet app. the behaviour on iOS is according to spec, on Android it is not.

In iOS steps are like this:

1. scan QR Code
2. display cert details and SAVE button
3. tap on SAVE
4. input TAN

Describe the bug

For REC Certificates Only the Ones which Are Valid at Least 2 Days After the Day of Travel Are Found During Checkin/Booking. But Certificates which expire one or two days after the day of travel are not offered by the wallet app although the names match.

For Example -- travel date is 08. October 2021 and in the wallet app are REC certificates which expire on: A) 08. October 2021; B) 09. October 2021; C) 10. October 2021; D) 11. October 2021; E) 12. October 2021.

All the data (incl. Name ) are identical in all of the certificates, only the expiry dates differ as shown above. Given a travel date of 08. October 2021, the wallet app matches only certificates D) and E). See attached Video.

Expected behaviour

All certificates should be matched because they are all valid with respect to the date of travel.

Technical details

Wallet App Version 1.2.3-acc (19) Galaxy XCover 4, Android 9

https://user-images.githubusercontent.com/76050122/136432174-ffd27a01-01e6-4b89-942b-c61dd0a0efd3.mp4

Describe the bug

Upon claiming the following QR Code, all previously saved certificates got deleted.

The logs are attached. The event happaned around 10:29 o'clock, 15.07.22.

Initial state: one or more certificates are already claimed and successfully saved on device Step 1: Scan attached Code Step 2: Type in Tan Step 3: Press save -- > the screen "No certificate available is shown" (attached Image)

Observed Behavior

After saving all previously saved certificates are deleted and no certificate is saved.

Additional Info

Furthermore, once in this state -- no other certificate can be saved any more on the device.

Expected behaviour

Certificate is successfully saved additionally to the rest of previously saved certificates.

Technical details

Wallet App 1.1.0-tst Galaxy XCover 4, Android 9

Logs

logcat.txt

Possible Fix

Additional context

Describe the bug

Thank you for making an open source application that is avilable on F-Droid.

I am using version 1.0.7-tst.

When attempting to add my EU Digital Covid certificate issued in Germany I can scan the code and the application correctly reads the details. However, I get the above error when hitting "save".

Expected behaviour

It should be able to add the certificate just fine.

Is this because of a syncing issue or something else? My certificate was issued a few hours ago.

Describe the bug

When manually start the synchronisation, the app will crash

Steps to reproduce the issue

1. go to settings
2. click on "update recovation state"

Technical details

• Pixel 3a XL
• Android 12

As part of fixing #50, this removes the dependency on the proprietary Google Licenses activity, and replaces it with a free implementation

Related to #37

Please note, this was inspired by https://github.com/mozilla-mobile/fenix/pull/13767/ and as such the LicensesActivity is under the MPL 2.0. I have reached out to the author to ask for a copy of the corresponding file under Apache 2.0, but even if that ends up not being possible it should also be noted that the MPL is compatible with Apache 2.0.

Current Implementation

App is likely only planned to be released in Google Play Store.

Suggested Enhancement

It would be great to see this Android app on F-Droid!

F-Droid is an Android app store specifically for free/libre open-source apps. It would be great if your app could be released there, as it is the number one for getting FLOSS Android apps for many people. F-Droid also builds all apps from source (optionally even reproducible), so downloads from there can be trusted.

The app developer FAQ or the quick start guide may help you to get started.

BTW a release on F-Droid could also bring some (more) popularity (in case that is intended), as it will show up in the app (new apps are featured there).

Expected Benefits

The benefits are trust (that the code shown here is the code you deliver), security (as untrusted modification of the code is nearly impossible then and you make an independent analysis possible) an increased user base/alternative installation options combined with an increased robustness by not having a single point of failure (Google Play Store) for app delivery. And also, as said, popularity/marketing if it is visible in the main F-Droid store.

See also https://github.com/corona-warn-app/cwa-app-android/issues/1483 for the same issue for the German Corona-Warn-App that explains more advantages especially of reproducible builds.

Description

The wallet-app encrypts internal data, the qr code and tan using the keystore. The chosen encryption scheme in class SecurityKeyWrapper and DefaultKeyStoreCryptor is ECB. ECB produces identical encrypted data and is thus not recommended for multi block data. There is also no documentation of the security model this security features is modeled for so its not possible to say if the feature is now faulty. While potentially not a meaningful issues for the presented data its not best practices and might be an issues later if template extend the use case.

Possible Fix

Use a more secure encryption scheme in the wallet app.

Impact

Wallet-app data storage encryption scheme slightly leaks protected data.

Description

The wallet-app is protected by login dialog. The dialog is depending on the device features protected by biometrics or another device unlock method. However it always wrongly claims to be a biometric login even on phone not supporting biometrics.

In class AuthFragment ; val prompt = BiometricPrompt.PromptInfo.Builder() .setTitle(getString(R.string.biometric_dialog_title)) .setSubtitle(getString(R.string.biometric_dialog_subtitle))

Possible Fix

Always uses these hardcoded values: Biometric login Log in using your biometric credential This security feature wrongly advertises itself and gives a false sense of security.

Impact

Wallet-app login suggest biometric level security on non-biometric devices. Recommendation: • Change login screen text and design accordingly on non-biometric devices.

The problem is that when one certificate is claimed more than one time, only the last claimed become to the prior certificate. Means that only for this newest claimed the public keys are can be found in the gateway. So for the older claimed (on other devices or on the same device) the revokation reload function fails with 400 in the API.

Possible solution should be to ask for the information from the gateway for every single one certificate and not only to get answer for the whole set of certificates.

@SchulzeStTSI maybe you can explain possible solution here in detail.

Please consider using a monospaced font for the certificate metadata to make it easier to spot typos committed by the institution issuing the certificate, both in the smartphone apps and on the actual PDFs that are printed out and handed to the person obtaining their certificate.

Currently the PDF uses the worst possible choice of font for this use case: a) a sans-serif font, which makes it difficult to spot certain typos and spelling mistakes (for example "m" vs "rn"), and b) blue instead of black text, which results in grey text on the printout in practice, which can be poorly rasterized depending on the exact printer configuration.

In my specific case, the institution issuing the certificate for my booster vaccination spelled my last name as "Emster" instead of "Ernster", and it took me a whole month to notice this. I had double-checked the spelling on the printout but even though I'm the type of person that routinely spots "two spaces instead of one" isses in printed text, hadn't noticed this misspelling. And even though I had wondered why the third certificate showed up in the German "Corona Warn App" as if it had been issued to a different person, I originally attributed this to the fact that the vaccine used for my booster vaccination was not the same as the one used for my initial two vaccinations. I only found the spelling mistake when I checked the certificate's Standardized Name, First Name field in the CWA, since all characters in this field are spelled in upper case.

You can probably even tell the advantage of monotype fonts for this use case when comparing the two in your browser:

• "Ernster" vs "Emster"
• Ernster vs Emster

When we try to export a DCC Certificate from the Android Wallet App via NFC onto the iOS wallet app, no certificate is seen in the destination app (iOS Wallet) although it says "Fertig". See attached Screenshot.

Expected behaviour

The chosen certificate is shown in the wallet app in the iOS device.

Actual behaviour

No certificate is to be seen in the iOS wallet App.

Steps to reproduce the issue

1. Open a saved certificate in the Android Wallet App;
2. Turn NFC switch on;
3. On the iOS device open the wallet App --> NFC Import;
4. Position the two devices with the back sides against each other until the iOS device shows the screen with text: "Bereit zum Scannen".

Technical details

Android Wallet App 1.2.2 acc Galaxy XCover 4, Android 9

iOS Wallet App 1.2.0.1 iPhone 5s, iOS 12.5.1