full-disclosure - [FD] Vipps by DNB for Android

Open Source and information security mailing list archives

Date: Wed, 02 Mar 2016 22:22:02 +0100
From: alendal@....hush.com
To: fulldisclosure@...lists.org
Subject: [FD] Vipps by DNB for Android - cryptographic vulnerabilities

============================
Summary:
=========
Application: Vipps by DNB
Operating system: Android
Versions affected: 1.1.33, 1.2.18, 1.2.20, 1.2.44 and 1.2.45
Non-vulnerable version: 1.3.0
Bugs: Cryptographic issues
Vendor notification: 16.02.2016
Vendor fix: 29.02.2016
Author: Gunnar Alendal, alendal (at) nym.hush.com

General description:
====================
The mobile app Vipps for Android has two cryptographic issues regarding generation of AES key material used to protect data in transit.
Vipps generates AES keys used for various encryption needs. This is done in a non-standard way, reducing the strength of the key material expected in AES encryption.

Vulnerability 1 - poor choice of PRNG:
=============================
Description:
-------------
An AES key generation method generates random keys used to encrypt sensitive data in transit. This method utilizes the java class java.util.Random. The method does not seed the random generator.

Effect of vulnerability:
------------------------
java.util.Random is not considered cryptographically safe for AES key generation.
Ref: http://resources.infosecinstitute.com/random-number-generation-java/

Possible fix:
-------------
java.security.SecureRandom is a better choice.

Vulnerability 2 - reducing the AES 256-bit key space
===========================================
Description:
-------------
An AES key generation method generates AES-256 keys which are in a small sub-space of the full 2^256 key space for AES-256. The method uses a PRNG to choose bytes from the character set "0123456789qwertyuiopasdfghjklzxcvbnm" only. This means each byte in the 32 byte AES key can only have one of 36 possible values, instead of one of 256.

Looking at the complexity of this, first by looking at the normal, full 2^256 key space:
* each byte can be one of 256 values
  ==> 2^8 possibilities per byte.
* there are 32 bytes in a key
  ==> (2^8)^32 = 2^256 possible 32-byte keys.

Looking at the key space generated by the vulnerable AES key generation method:
* each byte can be one of 36 values
  ==> ~ 2^5.16992500144 possibilities per byte.
* there are 32 bytes in a key
  ==> (2^5.16992500144)^32 = 2^165.43760004608 possible 32-byte keys.

Putting this in perspective: cutting the key space of 2^256 in half ==> key space size is reduced to 2^255.
Do this 89 more times to get the key space of this AES key generation method.

Effect of vulnerability:
------------------------
The size of the AES key space for a 32-byte key from the AES key generation method is reduced from the expected 2^256 to a much smaller 2^165.43760004608.
This means that the expected key space for AES-256 is 1 828 095 440 416 494 618 972 737 469 times bigger than the key space provided by this function.

Possible fix:
-------------
Use a cryptographically safe PRNG to generate a key where each byte is one of 256 possible values, instead of choosing from a fixed 36 character subset. This key is never transmitted in clear and does not need to be restricted to a "printable" character set. Even if so, one should encode the key _after_ generating a key from the full 2^256 key space.
============================

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives