Secure conditional branches

Table of Contents

• Problem definition
• Secret data
• Single branches
• Signing API
• Verification API

This document provides the rationale for security-related conditional branches.

Problem definition

We consider the following problems with conditional branches:

1. Single upset events.

   A single upset event can flip a single bit in the status register of the underlying hardware that controls the conditional branch. For example, the condition 'authentication succeeded' could be reversed.

2. Fault injections.

   An attacker may (e.g., by clock glitching) make the underlying hardware skip an instruction. A well-timed attack could skip the conditional branch instruction completely, effectively making the hardware behave as if the condition was false irrespective of its actual value.

3. Data leakage.

   An attacker may be able to observe the consumed power or the total running time to determine whether or not the branch condition was true or false. If the branching condition was based on secret data, (parts of) the secret data are leaked by such attacks, compromising confidentiality.

Secret data

The API never branches on secret data. This is also a PQClean requirement.

Single branches

Consider the following code:

if (!authentication_succeeded)
{
    return;
}
// actions follow that require authentication

A single, well-timed instruction skip could bypass the authorization check entirely.

Now consider the following code:

#pragma optimize(off)
if (authentication_succeeded == RESILIENT_FALSE)
{
    return;
}
if (authentication_succeeded != RESILIENT_TRUE)
{
    return;
}
#pragma optimize(restore)
// actions follow that require authentication

This requires at least two branch instructions to be skipped, which is a much harder feat to accomplish for an attacker. Furthermore, the branch condition uses bit error resilient values as explained in Secure boolean functions.

It is up to the user of the XMSS library to determine to which degree instruction-skip resilience is required. Note that compilers must be instructed to not optimize away any redundant condition checks.

Signing API

The signing API uses twofold condition redundancy.

Verification API

The verification API returns a type of which the defined values have a hamming-distance of 4 (see Secure boolean functions for a rationale). It is up to the user to do secure conditional branching on the returned value for the desired level of fault injection resilience. See Signature verification for guidance on secure usage the verification API for specific usage scenarios and security requirements.