Back in February we were contacted by Hanno Böck who had discovered an issue with how certain devices generate the nonce for AES-GCM and subsequently published a paper on the topic and the bug was assigned CVE-2016-0270.
Even though in our case the bug had low severity, we tracked down the source and corrected the bug in version 2.7.2-P8 of the software.
In summary Hanno defines three categories of how nonces are generated:
The first group is the correct way to generate the nonce. This ensures that a particular nonce will repeat after 2^64 records and calculated the probability of that many operations within a single session, thus proving this is secure.
The second group is a disaster. Repeating nonces if is sufficient to recover the the authentication key thus this implementation would reveal a critical vulnerability.
The third option hedges the probability of repeating a nonce randomly. With a good random number generator (RNG) the probability of collision is fairly low unless the session is used to transfer large amount of data, since after 2^32 records the probability rapidly increases. In other words there is a vague theoretical probability this can be broken if an attacker was to have the time and the victim produce exuberant amounts of data in the same session. In the paper Hanno is estimating something on the order of Terabytes in a session which for the use of load balancers is not an issue. It does become a potential issue in long lived VPN connections though.
The A10 devices before we corrected the problem did fit in the “random” category. As of versions 2.7.2-p8, this issue has been resolved.
Despite the low probability for exploitation we would like to thank Hanno for disclosing this highly complex vulnerability, and even further to point out that he followed responsible disclosure practices and worked with us while we were investigating the origin of the vulnerability.