Why does my TPM-chip report to support symmetric encryption algorithms, while not supporting symmetric encryption

Question

I would like to use my TPM chip to symmetrically encrypt some data, but sadly the tpm2_getcap commands command states that symmetric encryption is not supported by my chip.

The thing I find unusual is that the tpm2_getcap algorithms command states that there is AES support:

aes:
  value:      0x6
  asymmetric: 0
  symmetric:  1
  hash:       0
  object:     0
  reserved:   0x0
  signing:    0
  encrypting: 0
  method:     0

Why does my TPM chip (Infineon SLB9670) support AES, while it does not support symmetrically encrypting and decrypting?

---

In TPM-Rev-2.0-Part-1-Architecture-01.38 chapter 32.5 Symmetric Encryption the following is said:

Support for this command in a TPM may cause the TPM to be subject to different jurisdictions' legal import/export controls than would apply to a TPM without these commands.

Maybe this has something to do with AES being available, but not being able to use it?

Answer 1

It would seem this functionality is not supported by the SLB9670.

The chip reportedly does not support commands 0x164 and 0x193 which tpm2_encryptdecrypt depends on.

https://github.com/tpm2-software/tpm2-tools/issues/407

As to why it supports AES:

The SLB9670_1.2 supports the AES algorithm with key sizes of 128 bits for encryption and decryption. The function is used to support the transportation functionality and to support the temporary cashing of keys outside the TPM and for the personalisation of code and data.

Quote from Security Target for SLB9670_1.2 v1.2 pg 11

As to why it's not supported externally:

I can't find a direct quote from Infineon on this. To your Export restrictions quote, these are usually on AES-256 not 128 and generally apply anywhere it's used, not just were it's made available. But there could be something there

If I had to guess it was a budgetary decision. It would cost more to develop chip logic and APIs which support AES externally. Or the AES accelerator on the chip was sized just big enough to do transport crypto and wrapping but would be woefully slow for anything more. What also points to this is later in the document it mentions the accelerator only supports CBC and CTR, the very minimum subset of modes.