App Deutsche Bank PhotoTan firmata con certificato autofirmato?

1

Deutsche Bank ha recentemente iniziato a costringere i propri clienti a passare l'autenticazione delle transazioni da iTAN a PhotoTAN. Ora volevo verificare l'autenticità dell'app Android in questo modo:

# jarsigner -verify -verbose:all -certs com.db.pbc.phototan.db-1.apk

s       11870 Mon Oct 02 12:46:02 CEST 2017 META-INF/MANIFEST.MF

       X.509, CN=George Georgiades, OU=GT AS Productivity & Collaboration Technologies, O=Deutsche Bank AG, L=London, ST=Unknown, C=UK
       [certificate is valid from 10/31/11 12:42 PM to 3/18/39 12:42 PM]
       [CertPath not validated: Path does not chain with any of the trust anchors]

       11991 Mon Oct 02 12:46:02 CEST 2017 META-INF/DBANDROI.SF
        1525 Mon Oct 02 12:46:02 CEST 2017 META-INF/DBANDROI.RSA
sm      3468 Fri Nov 30 01:00:00 CET 1979 AndroidManifest.xml

       X.509, CN=George Georgiades, OU=GT AS Productivity & Collaboration Technologies, O=Deutsche Bank AG, L=London, ST=Unknown, C=UK
       [certificate is valid from 10/31/11 12:42 PM to 3/18/39 12:42 PM]
       [CertPath not validated: Path does not chain with any of the trust anchors]

... e così via, per tutti i file nell'APK. Quindi, naturalmente, mi chiedo chi sia questo George Georgiades e perché non abbia una catena di fiducia:

# unzip -p com.db.pbc.phototan.db-1.apk META-INF/DBANDROI.RSA | openssl pkcs7 -inform DER -noout -print_certs -text

Certificate:
Certificate:
Data:
    Version: 3 (0x2)
    Serial Number: 705392378 (0x2a0b6efa)
Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=UK, ST=Unknown, L=London, O=Deutsche Bank AG, OU=GT AS Productivity & Collaboration Technologies, CN=George Georgiades
    Validity
        Not Before: Oct 31 11:42:49 2011 GMT
        Not After : Mar 18 11:42:49 2039 GMT
    Subject: C=UK, ST=Unknown, L=London, O=Deutsche Bank AG, OU=GT AS Productivity & Collaboration Technologies, CN=George Georgiades
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:99:e5:d6:19:be:44:f7:f6:36:69:00:fd:01:28:
                7b:d0:5c:5d:84:52:d2:69:46:1c:d7:23:88:0a:4e:
                a8:51:71:2b:29:65:5f:97:92:d6:d8:c0:c2:22:84:
                e8:ae:ad:98:55:76:82:36:7e:94:1e:cc:7f:80:c1:
                0c:c3:1f:30:b2:f7:35:e9:24:2d:68:b6:a6:15:2c:
                12:d4:f3:cc:35:09:3c:fc:7f:b2:8b:3c:eb:98:7a:
                52:7a:11:f4:f0:81:55:d0:7c:80:ae:0e:fb:83:4f:
                76:32:53:1b:a3:4b:78:20:68:6e:d9:0f:16:46:d4:
                40:e7:fb:47:59:8f:9f:95:a4:68:c4:78:d9:37:c5:
                e4:5f:16:84:9e:9c:3b:d1:9c:c5:73:c3:35:87:67:
                8c:f4:cd:af:eb:70:f1:f9:ac:8c:bd:b2:13:8c:d3:
                60:ae:b2:25:e5:41:af:1a:0f:0c:85:dc:87:70:c9:
                41:73:e5:77:52:3f:61:ad:bc:99:18:7b:37:5d:a9:
                bc:53:1b:7e:4e:52:a4:15:7d:7a:7d:22:fa:2b:f5:
                0f:7e:26:70:6d:c4:e6:f6:47:f7:c9:1d:38:01:e0:
                36:3d:24:4a:f2:f1:08:33:3a:f6:fc:5e:4b:a3:cf:
                a7:ee:fc:54:fc:95:2b:ef:71:6e:36:f3:d5:c4:8b:
                9e:1f
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Subject Key Identifier: 
            5F:11:C3:FC:CD:7C:20:B9:10:4D:04:22:32:37:90:B3:85:EB:A6:DF
Signature Algorithm: sha256WithRSAEncryption
     20:21:b3:48:89:14:5d:30:53:3a:7f:72:cf:4b:4c:84:f8:c3:
     3b:4d:2c:9f:58:b9:d6:6c:fc:ef:8f:81:c2:4a:07:97:5e:28:
     10:3e:b3:6a:4b:9b:38:2b:8e:ca:07:a0:ae:aa:b8:3f:45:11:
     b5:84:62:2c:03:67:66:76:9c:d4:2b:b0:5b:15:45:86:9e:01:
     41:5c:1c:ea:9c:36:d0:ef:e3:ab:a4:3f:54:ae:2f:e9:b0:63:
     5f:c1:a2:e4:5b:d0:5d:66:a8:3c:d4:db:54:38:e1:b2:60:ba:
     c9:48:b7:ed:39:e9:fb:47:63:b4:17:ca:d4:2c:56:2f:d5:82:
     50:77:b6:46:d5:ca:b6:cf:8f:6a:34:d6:ba:2b:05:c9:04:7b:
     65:a8:ea:72:18:2d:f2:fa:e8:7c:1b:92:44:24:dd:e0:e6:47:
     9a:88:bc:a4:82:85:d2:8f:45:1c:41:3b:84:08:80:7c:cf:98:
     2d:90:06:f9:e1:c9:08:a3:26:6d:64:a2:f7:38:f0:4a:05:b1:
     ef:84:d4:e6:df:a4:4e:fc:f0:11:c0:0d:1d:bc:6e:8d:11:22:
     09:52:37:bb:52:d8:5e:70:d4:50:02:36:d5:bd:ed:bf:ba:1e:
     eb:34:e2:17:ec:9d:6f:4c:7f:4e:9f:b0:e7:4c:2a:17:57:50:
     2e:72:83:e1

Quindi ora sto pensando che il WTF stia succedendo ?? Perché il autenticatore di transazioni di Deutsche Bank sembra essere stato sviluppato da un tizio di Londra che utilizza un certificato autofirmato per firmarlo? O sono molto confuso su come la sicurezza delle app Android dovrebbe funzionare, o l'app è un falso, o questo è solo altamente poco professionale. Quale è?

    
posta Victor Mataré 29.09.2018 - 17:13
fonte

1 risposta

1

I'm very confused about how Android app security is supposed to work

Le app Android utilizzano generalmente certificati autofirmati per la firma dell'APK. La chiave di firma non è lì per stabilire l'identità del mondo reale, ma è solo a scopo di confronto con le chiavi di firma utilizzate da altri APK e il firmware installato sul dispositivo. Ad esempio, se un APK funge da aggiornamento per un APK installato, entrambi gli APK devono firmare con la stessa chiave di firma (fino a Android 9.0, quando la storia è diventata un po 'più complicata).

Suppongo che sia possibile per un'app utilizzare un certificato supportato dalla CA per firmare l'APK. Non l'ho mai fatto in questo modo e la documentazione dello sviluppatore Android mostra l'utilizzo di un certificato autofirmato .

    
risposta data 29.09.2018 - 17:33
fonte

Leggi altre domande sui tag