¿La aplicación PhotoTan de Deutsche Bank firmó con un certificado autofirmado?

1

Deutsche Bank recientemente comenzó a forzar a sus clientes a cambiar su autenticación de transacción de iTAN a PhotoTAN. Ahora quería verificar la autenticidad de la aplicación de Android de esta manera:

# 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]

... y así sucesivamente, para todos los archivos en el APK. Así que, naturalmente, me pregunto quién es este George Georgiades y por qué no tiene una cadena de confianza:

# 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

¿Entonces ahora estoy pensando que WTF está pasando? ¿Por qué el autenticador de transacciones de Deutsche Bank aparentemente está siendo desarrollado por un tipo en Londres que usa un certificado autofirmado para firmarlo? O estoy muy confundido acerca de cómo se supone que funciona la seguridad de la aplicación de Android, o la aplicación es una falsificación, o esto es simplemente poco profesional. ¿Cuál es?

    
pregunta Victor Mataré 29.09.2018 - 17:13
fuente

1 respuesta

1
  

Estoy muy confundido acerca de cómo se supone que funciona la seguridad de la aplicación Android

Las aplicaciones de Android generalmente usan certificados autofirmados para firmar el APK. La clave de firma no está ahí para establecer la identidad del mundo real, sino únicamente con fines de comparación con las claves de firma utilizadas por otros APK y el firmware instalado en el dispositivo. Por ejemplo, para que un APK sirva como actualización para un APK instalado, ambos APK deben estar firmados por la misma clave de firma (hasta Android 9.0, cuando la historia comenzó a complicarse un poco más).

Supongo que es posible que una aplicación utilice un certificado respaldado por CA para firmar el APK. Nunca lo he hecho así, y la documentación del desarrollador de Android muestra usando un certificado autofirmado .

    
respondido por el CommonsWare 29.09.2018 - 17:33
fuente

Lea otras preguntas en las etiquetas