DA Lockout without using any Password Protection

[GalaxyGorilla]

I'm working in an IoT like environment where user provided passwords for accessing a TPM are no viable option. The TPM is really just used as a crypto processor where the SRK is used to en-/decrypt small chunks of data during the early boot stage (using tss2_encrypt and tss2_decrypt).

I ran into a problem using the FAPI where the device gets locked out due to perceived DA attacks. In fact I get locked out after the 5th boot, so the 6th boot attempt fails like this:

Please excuse sending images here ... I got no proper access to those logs. I hope the stack trace can be of value.

My FAPI profile is this one here:

{
    "type": "TPM2_ALG_RSA",
    "nameAlg":"TPM2_ALG_SHA256",
    "srk_template": "system,decrypt,0x81000001",        <-- ADDING 'noda' HERE FIXES THE ISSUE!
    "srk_description": "Storage root key SRK",
    "srk_persistent": 1,
    "ek_template":  "system,restricted,decrypt",
    "ek_description": "Endorsement key EK",
    "rsa_signing_scheme": {
        "scheme":"TPM2_ALG_RSAPSS",
        "details":{
            "hashAlg":"TPM2_ALG_SHA256"
        }
    },
    "rsa_decrypt_scheme": {
        "scheme":"TPM2_ALG_OAEP",
        "details":{
            "hashAlg":"TPM2_ALG_SHA256"
        }
    },
    "sym_mode":"TPM2_ALG_CFB",
    "sym_parameters": {
        "algorithm":"TPM2_ALG_AES",
        "keyBits":"128",
        "mode":"TPM2_ALG_CFB"
    },
    "sym_block_size": 16,
    "pcr_selection": [
        { "hash": "TPM2_ALG_SHA1",
          "pcrSelect": [ ]
        },
        { "hash": "TPM2_ALG_SHA256",
          "pcrSelect": [ ]
        }
    ],
    "exponent": 0,
    "keyBits": 2048,
    "session_hash_alg": "TPM2_ALG_SHA256",
    "session_symmetric":{
        "algorithm":"TPM2_ALG_AES",
        "keyBits":"128",
        "mode":"TPM2_ALG_CFB"
    },
    "ek_policy": {
        "description": "Endorsement hierarchy used for policy secret.",
        "policy":[
            {
                "type":"POLICYSECRET",
                "objectName": "4000000b"
            }
        ]
    }
}

The issue can be fixed using the noda flag in the SRK template. However, given the fact that I just don't use password protection anywhere I wonder why this is a problem at all, e.g. maybe it is a software bug. Note that every en- and decryption using the TPM works during the first 5 boot procedures. Some idea what's going on here?

[JuergenReppSIT]

with your profile I could execute: echo 123 |tss2_encrypt -p /HS/SRK -i- -o-| tss2_decrypt -p /HS/SRK -i- -o- more than 5 times. Does the error also occur if you execute these commands more than 5 times? If not could you send the tss2 commands which are executed during the boot process? Are there any other error messages before the decrypt error?

[GalaxyGorilla]

I actually do several decrypts on one boot procedure. My feeling is that the number of power cycles matters, e.g. I always cut off the power of the device and then restart.

Do you see any trouble regarding the noDA flag? The specs seem to be very clear that this just prevents lockout protection for that particular key, which is fine for me.

I will invest more time next week to provide more information here. Thanks for the first test :).

[JuergenReppSIT]

@GalaxyGorilla yes I also now could reproduce your error if I cut off the power between executing the decrypt command. @AndreasFuchsTPM @PeterHuewe Any ideas what's the reason for this error?

[cplappert]

Hi, according the TPM spec, this is intended behavior to avoid an attacker bypassing the DA mechanism if the TPM is reset when a write to the NV version of failedTries is pending (cf. TPM Spec Part 1 Architecture, 19.8.6. Non-orderly Shutdown). Did you try to use the TPM2_Shutdown (tpm2_shutdown with the tools) command before cutting off the power to execute a orderly shutdown? I think this should help.

[GalaxyGorilla]

@cplappert Many thanks for the research in the spec! I could give the tpm2_shutdown a shot next week and will inform you about the results. However, this doesn't solve my particular problem. If power is gone ... it's gone, no time calling some shutdown functions :). I could in theory make use of transient power given by goldcaps or whatever, but honestly that's too complicated and prone to failure. Out there in the field one has to deal with power outages.

My personal learning here so far is: never use TPMs in an IoT like setup without the noDA flag.

[cplappert]

I was not sure about your particular scenario. You could also try to actively trigger a reset of the noda counter, e.g., with tpm2_dictionarylockout, after boot. That would be an alternative to using the noDA flag.

Anyway, I am interested in your findings.

[JuergenReppSIT]

@cplappert @GalaxyGorilla Also thank you from me for the research in the spec :+1:

[idesai]

Being locked out is an expected scenario from system robustness point of view. Take ownership of the lockout and clear the dictionary-lockout.

[JuergenReppSIT]

Take ownership of the lockout and clear the dictionary-lockout.

An auth value for the lockout hierarchy can also be set using tss2_provision (-L, --authValueLockout=STRING) or a JSON encoded policy can be set in the FAPI profile (lockout_policy)

[AndreasFuchsTPM]

I hope everything is working now. I close this now since no update for a long time.

[GalaxyGorilla]

Yes, the solution via the noda flag works and it is IMHO also the 'goto' solution when using the FAPI in the context of IOT devices.

Many thanks to all people here!