Secure Monitor

Revision as of 22:47, 4 October 2017 by Qlutoo (talk | contribs) (→‎Id 0)

Secure Monitor Calls

The secure monitor provides two top level handlers of which each provides a range of sub handlers.

Secure Monitor Calls follow the ARM SMC calling convention up to a small change:

Bit number Bit mask Description
31 0x80000000 Set to 0 means Yielding Call; Set to 1 means Fast Call.
30 0x40000000 Set to 0 means SMC32 convention; Set to 1 means SMC64.
29-24 0x3F000000 Service Call ranges.
23-16 0x00FF0000 Must be zero.
15-8 0x0000FF00 Argument type. This is different from the ARM SMC calling convention.
7-0 0x000000FF Function number within the range call type.

If bit n is set in the argument type then parameter Xn is treated as a pointer and the kernel will setup address translation for it in svcCallSecureMonitor.

Id 0

Functions exposed to user-mode processes using svcCallSecureMonitor.

Sub-Id Name In Out
0xC3000401 SetConfig
0xC3000002 GetConfig (Same as Id 1 Sub-Id 4.)
0xC3000003 CheckStatus
0xC3000404 GetResult
0xC3000E05 ExpMod
0xC3000006 GetRandomBytes (Same as Id 1 Sub-Id 5.)
0xC3000007 #GenerateAesKek
0xC3000008 #LoadAesKey
0xC3000009 #CryptAes
0xC300000A #GenerateSpecificAesKey
0xC300040B #ComputeCmac
0xC300100C #LoadRsaPrivateKey
0xC300100D #PrivateRsa
0xC300100E #LoadRsaPublicKey
0xC300060F #PublicRsa
0xC3000610 #UnwrapRsaEncryptedAesKey
0xC3000011 #LoadRsaWrappedAesKey
0xC3000012 [2.0.0+] GenerateRsaKek

The overall concept here is the following:

  • All key material (AES and RSA) is stored in userspace, but it's encrypted with random AES kek's ("key encryption keys").
  • Each kek is generated as a function of an access key (picked at random).
  • The kek is generated differently depending on the #CryptoUsecase the key is used for.
    • This means: Each key is "locked" to the #CryptoUsecase it was designated for.
    • You can use a key for a different usecase, but you will only get garbage output.
  • After the kek has been generated, it is wrapped with a session-specific key and given back to userspace.
    • This means: Plaintext kek keys never leave TrustZone.
    • Further, this means: Actual AES/RSA keys never leave TrustZone.

GenerateAesKek

Takes an "access key" as input, an #CryptoUsecase.

Returns a session-unique kek for said usecase.

LoadAesKey

Takes a session kek created with #GenerateAesKek, and a wrapped AES key.

The session kek must have been created with CryptoUsecase_Aes.

CryptAes

Encrypts/decrypts using Aes (CTR and CBC).

Key must be set prior using one of the #LoadAesKey, #GenerateSpecificAesKey or #LoadRsaWrappedAesKey commands.

GenerateSpecificAesKey

Todo: This one seems unrelated to #CryptoUsecase.

LoadRsaPrivateKey

Takes a session kek created with #GenerateAesKek, and a wrapped RSA private key.

The session kek must have been created with CryptoUsecase_PrivateRsa.

PrivateRsa

Encrypts using Rsa private key.

Key must be set prior using the #LoadRsaPrivateKey command.

LoadRsaPublicKey

Takes a session kek created with #GenerateAesKek, and a wrapped RSA public key.

The session kek must have been created with CryptoUsecase_PublicRsa.

PublicRsa

Encrypts using Rsa public key.

Key must be set prior using the #LoadRsaPublicKey command.

UnwrapRsaEncryptedAesKey

Takes a session kek created with #GenerateAesKek, and a wrapped RSA public key.

Returns a session-unique AES key especially for use in #LoadRsaWrappedAesKey.

The session kek must have been created with CryptoUsecase_RsaWrappedAesKey.

LoadRsaWrappedAesKey

Takes a session-unique AES key from #UnwrapRsaEncryptedAesKey.

enum CryptoUsecase

Value Name
0 CryptoUsecase_Aes
1 CryptoUsecase_PrivateRsa
2 CryptoUsecase_PublicRsa
3 CryptoUsecase_RsaWrappedAesKey

Id 1

Functions exposed to the kernel internally.

Sub-Id Name In Out
0xC4000001 CpuSuspend (oyasumi)
0x84000002 CpuOff
0xC4000003 CpuOn
0xC3000004 GetConfig (Same as Id 0 Sub-Id 2.)
0xC3000005 GetRandomBytes (Same as Id 0 Sub-Id 6.)
0xC3000006 Panic
0xC3000007 [2.0.0+] ProtectKernelRegion
0xC3000008 [2.0.0+] ReadWriteRegister