[android-security-discuss] Apply for key attestation for hardware-backed keystore authentication

[d***@ff.com]

Get information from QCOM datasheet "Attestation key provision is mandatory
on new android O release, customer need do key attestation
before the CTS/VTS test. ", however, the information from Google is we have
to pass CTS before applying key attestation.
Which one is correct? Which department should we reach to to apply the
attestation key?

['Janis' via Android Security Discussions]

Hi,

CTS and VTS test do not check the origin of the root CA. So you can pass
these tests with a certificate chain rooted in a self signed CA. Once you
passed CTS and VTS you can get the Google signed keys. Please reach out to
your technical account manager at Google for the right process.

With kind regards,
Janis

Post by d***@ff.com
Get information from QCOM datasheet "Attestation key provision is
mandatory on new android O release, customer need do key attestation
before the CTS/VTS test. ", however, the information from Google is we
have to pass CTS before applying key attestation.
Which one is correct? Which department should we reach to to apply the
attestation key?

[d***@ff.com]

Janis, thank you for the reply. Good to know that we don't have to use
Google root CA for CTS test.
Our platform doesn't allow application installation from Google Playstore,
which means all the Apps are controlled and signed by ourselves. Can I
assume that in this case these Apps can also use our own cert-chain for
Keymaster authority check?

Post by 'Janis' via Android Security Discussions
Hi,
CTS and VTS test do not check the origin of the root CA. So you can pass
these tests with a certificate chain rooted in a self signed CA. Once you
passed CTS and VTS you can get the Google signed keys. Please reach out to
your technical account manager at Google for the right process.
With kind regards,
Janis

Post by d***@ff.com
Get information from QCOM datasheet "Attestation key provision is
mandatory on new android O release, customer need do key attestation
before the CTS/VTS test. ", however, the information from Google is we
have to pass CTS before applying key attestation.
Which one is correct? Which department should we reach to to apply the
attestation key?

['Janis' via Android Security Discussions]

Yes that is a perfectly viable. If you do not intend to use the Google
PlayStore you don't need a Google signed attestation key. Note, however,
that the attestation certificates issued by keymaster are checked by the
applications' service back ends. So if you allow apps from third parties
which use key attestation, their back ends may not trust your certificates
and reject the attestation certificates issued by your keymaster
implementation. You may need to negotiate with these vendors to white list
your CA. But if you control all of the apps it is up to you which CAs to
trust.

Post by d***@ff.com
Janis, thank you for the reply. Good to know that we don't have to use
Google root CA for CTS test.
Our platform doesn't allow application installation from Google Playstore,
which means all the Apps are controlled and signed by ourselves. Can I
assume that in this case these Apps can also use our own cert-chain for
Keymaster authority check?

Post by 'Janis' via Android Security Discussions
Hi,
CTS and VTS test do not check the origin of the root CA. So you can pass
these tests with a certificate chain rooted in a self signed CA. Once you
passed CTS and VTS you can get the Google signed keys. Please reach out to
your technical account manager at Google for the right process.
With kind regards,
Janis

Post by d***@ff.com
Get information from QCOM datasheet "Attestation key provision is
mandatory on new android O release, customer need do key attestation
before the CTS/VTS test. ", however, the information from Google is we
have to pass CTS before applying key attestation.
Which one is correct? Which department should we reach to to apply the
attestation key?

[d***@ff.com]

What's the relation between keybox and attestation_cert_chain. Is keybox
the private key and the end-node "ATTESTATION_CERTIFICATE" of the
cert-chain is the certificate of that keybox?
Should the keybox key pair be generated inside TEE or generated from
external?


Here is sample keybox:

<Keybox DeviceID="XXXX"><Key algorithm="ecdsa"><PrivateKey format="pem">
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIPkqUSMK5bPQntppGeSsFcbXRcMWC2bx1lRpGaZEIrq/oAoGCCqGSM49
AwEHoUQDQgAEalaoKb/I5S9bpfDVzAYymLaJJowm59uojupRL/CY87KcCjeULbcB
QirzI2TcpH5ATmUc+qGtnyYwBaWSy0h7nQ==
-----END EC PRIVATE KEY-----


Here is sample cert-chain from "googlesamples
<https://github.com/googlesamples>/android-key-attestation
<https://github.com/googlesamples/android-key-attestation>"
https://github.com/googlesamples/android-key-attestation/blob/master/server/src/main/java/com/android/example/KeyAttestationExample.java

public static final String[] SAMPLE_ATTESTATION_CERT_CHAIN = new String[]{
ATTESTATION_CERTIFICATE, INTERMEDIATE_CERTIFICATE, ROOT_CERTIFICATE
};
-----BEGIN CERTIFICATE-----
MIICizCCAjKgAwIBAgIJAKIFntEOQ1tXMAoGCCqGSM49BAMCMIGYMQswCQYDVQQGEw
JVUzETMBEG A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzE
VMBMGA1UECgwMR29vZ2xl LCBJbmMuMRAwDgYDVQQLDAdBbmRyb2lkMTMwMQYDVQQD
DCpBbmRyb2lkIEtleXN0b3JlIFNvZnR3 YXJlIEF0dGVzdGF0aW9uIFJvb3QwHhcNM
TYwMTExMDA0MzUwWhcNMzYwMTA2MDA0MzUwWjCBmDEL MAkGA1UEBhMCVVMxEzARBg
NVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcx FTATBgNVBAo
MDEdvb2dsZSwgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEzMDEGA1UEAwwqQW5kcm9p
ZCBLZXlzdG9yZSBTb2Z0d2FyZSBBdHRlc3RhdGlvbiBSb290MFkwEwYHKoZIzj0CAQ
YIKoZIzj0D AQcDQgAE7l1ex+HA220Dpn7mthvsTWpdamguD/9/SQ59dx9EIm29sa/
6FsvHrcV30lacqrewLVQB XT5DKyqO107sSHVBpKNjMGEwHQYDVR0OBBYEFMit6XdM
RcOjzw0WEOR5QzohWjDPMB8GA1UdIwQY MBaAFMit6XdMRcOjzw0WEOR5QzohWjDPM
A8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgKE MAoGCCqGSM49BAMCA0cAME
QCIDUho++LNEYenNVg8x1YiSBq3KNlQfYNns6KGYxmSGB7AiBNC/NR 2TB8fVvaNTQ
dqEcbY6WFZTytTySn502vQX3xvw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICeDCCAh6gAwIBAgICEAEwCgYIKoZIzj0EAwIwgZgxCzAJBgNVBAYTAlVTMRMwEQ
YDVQQIDApD YWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRUwEwYDVQQ
KDAxHb29nbGUsIEluYy4x EDAOBgNVBAsMB0FuZHJvaWQxMzAxBgNVBAMMKkFuZHJv
aWQgS2V5c3RvcmUgU29mdHdhcmUgQXR0 ZXN0YXRpb24gUm9vdDAeFw0xNjAxMTEwM
DQ2MDlaFw0yNjAxMDgwMDQ2MDlaMIGIMQswCQYDVQQG EwJVUzETMBEGA1UECAwKQ2
FsaWZvcm5pYTEVMBMGA1UECgwMR29vZ2xlLCBJbmMuMRAwDgYDVQQL DAdBbmRyb2l
kMTswOQYDVQQDDDJBbmRyb2lkIEtleXN0b3JlIFNvZnR3YXJlIEF0dGVzdGF0aW9u
IEludGVybWVkaWF0ZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOueefhCY1msyy
qRTImGzHCt kGaTgqlzJhP+rMv4ISdMIXSXSir+pblNf2bU4GUQZjW8U7ego6ZxWD7
bPhGuEBSjZjBkMB0GA1Ud DgQWBBQ//KzWGrE6noEguNUlHMVlux6RqTAfBgNVHSME
GDAWgBTIrel3TEXDo88NFhDkeUM6IVow zzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA
1UdDwEB/wQEAwIChDAKBggqhkjOPQQDAgNIADBFAiBL ipt77oK8wDOHri/AiZi03c
ONqycqRZ9pDMfDktQPjgIhAO7aAV229DLp1IQ7YkyUBO86fMy9Xvsi u+f+uXc/WT/
7
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIByTCCAXCgAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFBbmRyb2lkIE
tleW1hc3Rl cjAgFw03MDAxMDEwMDAwMDBaGA8yMTA2MDIwNzA2MjgxNVowGjEYMBY
GA1UEAwwPQSBLZXltYXN0 ZXIgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
FpsFUWID9p2QPAvtfal4MRf9vJg0tNc3 vKJwoDhhSCMm7If0FljgvmroBYQyCIbnn
Bxh2OU9SKxI/manPwIIUqOBojCBnzALBgNVHQ8EBAMC B4AwbwYKKwYBBAHWeQIBEQ
RhMF8CAQEKAQACAQEKAQEEBWhlbGxvBAAwDL+FPQgCBgFWDy29GDA6 oQUxAwIBAqI
DAgEDowQCAgEApQUxAwIBBKoDAgEBv4N4AwIBA7+DeQQCAgEsv4U+AwIBAL+FPwIF
ADAfBgNVHSMEGDAWgBQ//KzWGrE6noEguNUlHMVlux6RqTAKBggqhkjOPQQDAgNHAD
BEAiBKzJSk 9VNauKu4dr+ZJ5jMTNlAxSI99XkKEkXSolsGSAIgCnd5T99gv3B/IqM
CHn0yZ7Wuu/jisU0epRRo xh8otA8=
-----END CERTIFICATE-----

Post by 'Janis' via Android Security Discussions
Yes that is a perfectly viable. If you do not intend to use the Google
PlayStore you don't need a Google signed attestation key. Note, however,
that the attestation certificates issued by keymaster are checked by the
applications' service back ends. So if you allow apps from third parties
which use key attestation, their back ends may not trust your certificates
and reject the attestation certificates issued by your keymaster
implementation. You may need to negotiate with these vendors to white list
your CA. But if you control all of the apps it is up to you which CAs to
trust.

Post by d***@ff.com
Janis, thank you for the reply. Good to know that we don't have to use
Google root CA for CTS test.
Our platform doesn't allow application installation from Google
Playstore, which means all the Apps are controlled and signed by ourselves.
Can I assume that in this case these Apps can also use our own cert-chain
for Keymaster authority check?

Post by 'Janis' via Android Security Discussions
Hi,
CTS and VTS test do not check the origin of the root CA. So you can pass
these tests with a certificate chain rooted in a self signed CA. Once you
passed CTS and VTS you can get the Google signed keys. Please reach out to
your technical account manager at Google for the right process.
With kind regards,
Janis

Post by d***@ff.com
Get information from QCOM datasheet "Attestation key provision is
mandatory on new android O release, customer need do key attestation
before the CTS/VTS test. ", however, the information from Google is we
have to pass CTS before applying key attestation.
Which one is correct? Which department should we reach to to apply the
attestation key?

['Janis' via Android Security Discussions]

The keybox holds the private batch key. Batch keys are called "batch" keys
be cause they are used across a batch of at least 100K Android devices.
This is a privacy requirement.

Because of the batch nature of the attestation key it cannot be generated
in the TEE.

The keybox is very sensitive and you should only allow specially trained
personell to handle these and keep them tightly controlled, e.g, you don't
want to use the keybox posted above for anything but testing (I hope this
is obvious - just making sure). Also If you manage your own CA, you need to
manage your own revocation lists and revoke batch keys if you think they
have been compromised.

The chain consists of a root CA cert, one or more intermediate certificates
and a batch key certificate (I guess the example chain has 0
intermediates). The attestation certificate is at the end of this chain and
attests to a key generated in or imported into AndroidKeystore. It includes
the public key of the latter and a bunch of usage requirements, such as
purpose (SIGN, DECRYPT, ...), allowed digest and padding modes, whether
keys are authentication bound, or information about the root of trust (is
the bootloader locked ...).
Checkout https://source.android.com/security/keystore/attestation for a
full list of items that get attested to.

Post by d***@ff.com
What's the relation between keybox and attestation_cert_chain. Is keybox
the private key and the end-node "ATTESTATION_CERTIFICATE" of the
cert-chain is the certificate of that keybox?
Should the keybox key pair be generated inside TEE or generated from
external?
<Keybox DeviceID="XXXX"><Key algorithm="ecdsa"><PrivateKey format="pem">
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIPkqUSMK5bPQntppGeSsFcbXRcMWC2bx1lRpGaZEIrq/oAoGCCqGSM49
AwEHoUQDQgAEalaoKb/I5S9bpfDVzAYymLaJJowm59uojupRL/CY87KcCjeULbcB
QirzI2TcpH5ATmUc+qGtnyYwBaWSy0h7nQ==
-----END EC PRIVATE KEY-----
Here is sample cert-chain from "googlesamples
<https://github.com/googlesamples>/android-key-attestation
<https://github.com/googlesamples/android-key-attestation>"
https://github.com/googlesamples/android-key-attestation/blob/master/server/src/main/java/com/android/example/KeyAttestationExample.java
public static final String[] SAMPLE_ATTESTATION_CERT_CHAIN = new String[]{
ATTESTATION_CERTIFICATE, INTERMEDIATE_CERTIFICATE,
ROOT_CERTIFICATE};
-----BEGIN CERTIFICATE-----
MIICizCCAjKgAwIBAgIJAKIFntEOQ1tXMAoGCCqGSM49BAMCMIGYMQswCQYDVQQGEw
JVUzETMBEG A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzE
VMBMGA1UECgwMR29vZ2xl LCBJbmMuMRAwDgYDVQQLDAdBbmRyb2lkMTMwMQYDVQQD
DCpBbmRyb2lkIEtleXN0b3JlIFNvZnR3 YXJlIEF0dGVzdGF0aW9uIFJvb3QwHhcNM
TYwMTExMDA0MzUwWhcNMzYwMTA2MDA0MzUwWjCBmDEL MAkGA1UEBhMCVVMxEzARBg
NVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcx FTATBgNVBAo
MDEdvb2dsZSwgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEzMDEGA1UEAwwqQW5kcm9p
ZCBLZXlzdG9yZSBTb2Z0d2FyZSBBdHRlc3RhdGlvbiBSb290MFkwEwYHKoZIzj0CAQ
YIKoZIzj0D AQcDQgAE7l1ex+HA220Dpn7mthvsTWpdamguD/9/SQ59dx9EIm29sa/
6FsvHrcV30lacqrewLVQB XT5DKyqO107sSHVBpKNjMGEwHQYDVR0OBBYEFMit6XdM
RcOjzw0WEOR5QzohWjDPMB8GA1UdIwQY MBaAFMit6XdMRcOjzw0WEOR5QzohWjDPM
A8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgKE MAoGCCqGSM49BAMCA0cAME
QCIDUho++LNEYenNVg8x1YiSBq3KNlQfYNns6KGYxmSGB7AiBNC/NR 2TB8fVvaNTQ
dqEcbY6WFZTytTySn502vQX3xvw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICeDCCAh6gAwIBAgICEAEwCgYIKoZIzj0EAwIwgZgxCzAJBgNVBAYTAlVTMRMwEQ
YDVQQIDApD YWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRUwEwYDVQQ
KDAxHb29nbGUsIEluYy4x EDAOBgNVBAsMB0FuZHJvaWQxMzAxBgNVBAMMKkFuZHJv
aWQgS2V5c3RvcmUgU29mdHdhcmUgQXR0 ZXN0YXRpb24gUm9vdDAeFw0xNjAxMTEwM
DQ2MDlaFw0yNjAxMDgwMDQ2MDlaMIGIMQswCQYDVQQG EwJVUzETMBEGA1UECAwKQ2
FsaWZvcm5pYTEVMBMGA1UECgwMR29vZ2xlLCBJbmMuMRAwDgYDVQQL DAdBbmRyb2l
kMTswOQYDVQQDDDJBbmRyb2lkIEtleXN0b3JlIFNvZnR3YXJlIEF0dGVzdGF0aW9u
IEludGVybWVkaWF0ZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOueefhCY1msyy
qRTImGzHCt kGaTgqlzJhP+rMv4ISdMIXSXSir+pblNf2bU4GUQZjW8U7ego6ZxWD7
bPhGuEBSjZjBkMB0GA1Ud DgQWBBQ//KzWGrE6noEguNUlHMVlux6RqTAfBgNVHSME
GDAWgBTIrel3TEXDo88NFhDkeUM6IVow zzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA
1UdDwEB/wQEAwIChDAKBggqhkjOPQQDAgNIADBFAiBL ipt77oK8wDOHri/AiZi03c
ONqycqRZ9pDMfDktQPjgIhAO7aAV229DLp1IQ7YkyUBO86fMy9Xvsi u+f+uXc/WT/
7
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIByTCCAXCgAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFBbmRyb2lkIE
tleW1hc3Rl cjAgFw03MDAxMDEwMDAwMDBaGA8yMTA2MDIwNzA2MjgxNVowGjEYMBY
GA1UEAwwPQSBLZXltYXN0 ZXIgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
FpsFUWID9p2QPAvtfal4MRf9vJg0tNc3 vKJwoDhhSCMm7If0FljgvmroBYQyCIbnn
Bxh2OU9SKxI/manPwIIUqOBojCBnzALBgNVHQ8EBAMC B4AwbwYKKwYBBAHWeQIBEQ
RhMF8CAQEKAQACAQEKAQEEBWhlbGxvBAAwDL+FPQgCBgFWDy29GDA6 oQUxAwIBAqI
DAgEDowQCAgEApQUxAwIBBKoDAgEBv4N4AwIBA7+DeQQCAgEsv4U+AwIBAL+FPwIF
ADAfBgNVHSMEGDAWgBQ//KzWGrE6noEguNUlHMVlux6RqTAKBggqhkjOPQQDAgNHAD
BEAiBKzJSk 9VNauKu4dr+ZJ5jMTNlAxSI99XkKEkXSolsGSAIgCnd5T99gv3B/IqM
CHn0yZ7Wuu/jisU0epRRo xh8otA8=
-----END CERTIFICATE-----

Post by 'Janis' via Android Security Discussions
Yes that is a perfectly viable. If you do not intend to use the Google
PlayStore you don't need a Google signed attestation key. Note, however,
that the attestation certificates issued by keymaster are checked by the
applications' service back ends. So if you allow apps from third parties
which use key attestation, their back ends may not trust your certificates
and reject the attestation certificates issued by your keymaster
implementation. You may need to negotiate with these vendors to white list
your CA. But if you control all of the apps it is up to you which CAs to
trust.

Post by d***@ff.com
Janis, thank you for the reply. Good to know that we don't have to use
Google root CA for CTS test.
Our platform doesn't allow application installation from Google
Playstore, which means all the Apps are controlled and signed by ourselves.
Can I assume that in this case these Apps can also use our own cert-chain
for Keymaster authority check?

Post by 'Janis' via Android Security Discussions
Hi,
CTS and VTS test do not check the origin of the root CA. So you can
pass these tests with a certificate chain rooted in a self signed CA. Once
you passed CTS and VTS you can get the Google signed keys. Please reach out
to your technical account manager at Google for the right process.
With kind regards,
Janis

Post by d***@ff.com
Get information from QCOM datasheet "Attestation key provision is
mandatory on new android O release, customer need do key attestation
before the CTS/VTS test. ", however, the information from Google is we
have to pass CTS before applying key attestation.
Which one is correct? Which department should we reach to to apply the
attestation key?

[d***@ff.com]

Thanks.

The existing CA-chain I am going to integrate this leaf attest cert is a
mix of RSA CA and ECC CA. Does Android O allow this? Otherwise I will have
to create a new chain which is ECC only.
Does Android O allow different key strength in the chain, for example, I
use ECC-521 for root, and 384 for intermediate and then 256 for leaf.

Is there any sample config file I can refer to, to generate the batch key
certificate?

Post by 'Janis' via Android Security Discussions
The keybox holds the private batch key. Batch keys are called "batch" keys
be cause they are used across a batch of at least 100K Android devices.
This is a privacy requirement.
Because of the batch nature of the attestation key it cannot be generated
in the TEE.
The keybox is very sensitive and you should only allow specially trained
personell to handle these and keep them tightly controlled, e.g, you don't
want to use the keybox posted above for anything but testing (I hope this
is obvious - just making sure). Also If you manage your own CA, you need to
manage your own revocation lists and revoke batch keys if you think they
have been compromised.
The chain consists of a root CA cert, one or more intermediate
certificates and a batch key certificate (I guess the example chain has 0
intermediates). The attestation certificate is at the end of this chain and
attests to a key generated in or imported into AndroidKeystore. It includes
the public key of the latter and a bunch of usage requirements, such as
purpose (SIGN, DECRYPT, ...), allowed digest and padding modes, whether
keys are authentication bound, or information about the root of trust (is
the bootloader locked ...). Checkout
https://source.android.com/security/keystore/attestation for a full list
of items that get attested to.

Post by d***@ff.com
What's the relation between keybox and attestation_cert_chain. Is keybox
the private key and the end-node "ATTESTATION_CERTIFICATE" of the
cert-chain is the certificate of that keybox?
Should the keybox key pair be generated inside TEE or generated from
external?
<Keybox DeviceID="XXXX"><Key algorithm="ecdsa"><PrivateKey format="pem">
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIPkqUSMK5bPQntppGeSsFcbXRcMWC2bx1lRpGaZEIrq/oAoGCCqGSM49
AwEHoUQDQgAEalaoKb/I5S9bpfDVzAYymLaJJowm59uojupRL/CY87KcCjeULbcB
QirzI2TcpH5ATmUc+qGtnyYwBaWSy0h7nQ==
-----END EC PRIVATE KEY-----
Here is sample cert-chain from "googlesamples
<https://github.com/googlesamples>/android-key-attestation
<https://github.com/googlesamples/android-key-attestation>"
https://github.com/googlesamples/android-key-attestation/blob/master/server/src/main/java/com/android/example/KeyAttestationExample.java
public static final String[] SAMPLE_ATTESTATION_CERT_CHAIN = new String[]{
ATTESTATION_CERTIFICATE, INTERMEDIATE_CERTIFICATE,
ROOT_CERTIFICATE};
-----BEGIN CERTIFICATE-----
MIICizCCAjKgAwIBAgIJAKIFntEOQ1tXMAoGCCqGSM49BAMCMIGYMQswCQYDVQQGEw
JVUzETMBEG A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzE
VMBMGA1UECgwMR29vZ2xl LCBJbmMuMRAwDgYDVQQLDAdBbmRyb2lkMTMwMQYDVQQD
DCpBbmRyb2lkIEtleXN0b3JlIFNvZnR3 YXJlIEF0dGVzdGF0aW9uIFJvb3QwHhcNM
TYwMTExMDA0MzUwWhcNMzYwMTA2MDA0MzUwWjCBmDEL MAkGA1UEBhMCVVMxEzARBg
NVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcx FTATBgNVBAo
MDEdvb2dsZSwgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEzMDEGA1UEAwwqQW5kcm9p
ZCBLZXlzdG9yZSBTb2Z0d2FyZSBBdHRlc3RhdGlvbiBSb290MFkwEwYHKoZIzj0CAQ
YIKoZIzj0D AQcDQgAE7l1ex+HA220Dpn7mthvsTWpdamguD/9/SQ59dx9EIm29sa/
6FsvHrcV30lacqrewLVQB XT5DKyqO107sSHVBpKNjMGEwHQYDVR0OBBYEFMit6XdM
RcOjzw0WEOR5QzohWjDPMB8GA1UdIwQY MBaAFMit6XdMRcOjzw0WEOR5QzohWjDPM
A8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgKE MAoGCCqGSM49BAMCA0cAME
QCIDUho++LNEYenNVg8x1YiSBq3KNlQfYNns6KGYxmSGB7AiBNC/NR 2TB8fVvaNTQ
dqEcbY6WFZTytTySn502vQX3xvw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICeDCCAh6gAwIBAgICEAEwCgYIKoZIzj0EAwIwgZgxCzAJBgNVBAYTAlVTMRMwEQ
YDVQQIDApD YWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRUwEwYDVQQ
KDAxHb29nbGUsIEluYy4x EDAOBgNVBAsMB0FuZHJvaWQxMzAxBgNVBAMMKkFuZHJv
aWQgS2V5c3RvcmUgU29mdHdhcmUgQXR0 ZXN0YXRpb24gUm9vdDAeFw0xNjAxMTEwM
DQ2MDlaFw0yNjAxMDgwMDQ2MDlaMIGIMQswCQYDVQQG EwJVUzETMBEGA1UECAwKQ2
FsaWZvcm5pYTEVMBMGA1UECgwMR29vZ2xlLCBJbmMuMRAwDgYDVQQL DAdBbmRyb2l
kMTswOQYDVQQDDDJBbmRyb2lkIEtleXN0b3JlIFNvZnR3YXJlIEF0dGVzdGF0aW9u
IEludGVybWVkaWF0ZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOueefhCY1msyy
qRTImGzHCt kGaTgqlzJhP+rMv4ISdMIXSXSir+pblNf2bU4GUQZjW8U7ego6ZxWD7
bPhGuEBSjZjBkMB0GA1Ud DgQWBBQ//KzWGrE6noEguNUlHMVlux6RqTAfBgNVHSME
GDAWgBTIrel3TEXDo88NFhDkeUM6IVow zzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA
1UdDwEB/wQEAwIChDAKBggqhkjOPQQDAgNIADBFAiBL ipt77oK8wDOHri/AiZi03c
ONqycqRZ9pDMfDktQPjgIhAO7aAV229DLp1IQ7YkyUBO86fMy9Xvsi u+f+uXc/WT/
7
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIByTCCAXCgAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFBbmRyb2lkIE
tleW1hc3Rl cjAgFw03MDAxMDEwMDAwMDBaGA8yMTA2MDIwNzA2MjgxNVowGjEYMBY
GA1UEAwwPQSBLZXltYXN0 ZXIgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
FpsFUWID9p2QPAvtfal4MRf9vJg0tNc3 vKJwoDhhSCMm7If0FljgvmroBYQyCIbnn
Bxh2OU9SKxI/manPwIIUqOBojCBnzALBgNVHQ8EBAMC B4AwbwYKKwYBBAHWeQIBEQ
RhMF8CAQEKAQACAQEKAQEEBWhlbGxvBAAwDL+FPQgCBgFWDy29GDA6 oQUxAwIBAqI
DAgEDowQCAgEApQUxAwIBBKoDAgEBv4N4AwIBA7+DeQQCAgEsv4U+AwIBAL+FPwIF
ADAfBgNVHSMEGDAWgBQ//KzWGrE6noEguNUlHMVlux6RqTAKBggqhkjOPQQDAgNHAD
BEAiBKzJSk 9VNauKu4dr+ZJ5jMTNlAxSI99XkKEkXSolsGSAIgCnd5T99gv3B/IqM
CHn0yZ7Wuu/jisU0epRRo xh8otA8=
-----END CERTIFICATE-----

Post by 'Janis' via Android Security Discussions
Yes that is a perfectly viable. If you do not intend to use the Google
PlayStore you don't need a Google signed attestation key. Note, however,
that the attestation certificates issued by keymaster are checked by the
applications' service back ends. So if you allow apps from third parties
which use key attestation, their back ends may not trust your certificates
and reject the attestation certificates issued by your keymaster
implementation. You may need to negotiate with these vendors to white list
your CA. But if you control all of the apps it is up to you which CAs to
trust.

Post by d***@ff.com
Janis, thank you for the reply. Good to know that we don't have to use
Google root CA for CTS test.
Our platform doesn't allow application installation from Google
Playstore, which means all the Apps are controlled and signed by ourselves.
Can I assume that in this case these Apps can also use our own cert-chain
for Keymaster authority check?

Post by 'Janis' via Android Security Discussions
Hi,
CTS and VTS test do not check the origin of the root CA. So you can
pass these tests with a certificate chain rooted in a self signed CA. Once
you passed CTS and VTS you can get the Google signed keys. Please reach out
to your technical account manager at Google for the right process.
With kind regards,
Janis

Post by d***@ff.com
Get information from QCOM datasheet "Attestation key provision is
mandatory on new android O release, customer need do key attestation
before the CTS/VTS test. ", however, the information from Google is
we have to pass CTS before applying key attestation.
Which one is correct? Which department should we reach to to apply
the attestation key?

['Janis' via Android Security Discussions]

We usually have EC keys to attest to EC keys and RSA keys to attest to RSA
keys. And so are the intermediate certs. There is only one root CA cert
though for both chains. I would have to check back as to how strict this is
required. The key strength can vary. In the end it is important that the
chain can be verified.

Post by d***@ff.com
Thanks.
The existing CA-chain I am going to integrate this leaf attest cert is a
mix of RSA CA and ECC CA. Does Android O allow this? Otherwise I will have
to create a new chain which is ECC only.
Does Android O allow different key strength in the chain, for example, I
use ECC-521 for root, and 384 for intermediate and then 256 for leaf.
Is there any sample config file I can refer to, to generate the batch key
certificate?

Post by 'Janis' via Android Security Discussions
The keybox holds the private batch key. Batch keys are called "batch"
keys be cause they are used across a batch of at least 100K Android
devices. This is a privacy requirement.
Because of the batch nature of the attestation key it cannot be generated
in the TEE.
The keybox is very sensitive and you should only allow specially trained
personell to handle these and keep them tightly controlled, e.g, you don't
want to use the keybox posted above for anything but testing (I hope this
is obvious - just making sure). Also If you manage your own CA, you need to
manage your own revocation lists and revoke batch keys if you think they
have been compromised.
The chain consists of a root CA cert, one or more intermediate
certificates and a batch key certificate (I guess the example chain has 0
intermediates). The attestation certificate is at the end of this chain and
attests to a key generated in or imported into AndroidKeystore. It includes
the public key of the latter and a bunch of usage requirements, such as
purpose (SIGN, DECRYPT, ...), allowed digest and padding modes, whether
keys are authentication bound, or information about the root of trust (is
the bootloader locked ...). Checkout
https://source.android.com/security/keystore/attestation for a full list
of items that get attested to.

Post by d***@ff.com
What's the relation between keybox and attestation_cert_chain. Is keybox
the private key and the end-node "ATTESTATION_CERTIFICATE" of the
cert-chain is the certificate of that keybox?
Should the keybox key pair be generated inside TEE or generated from
external?
<Keybox DeviceID="XXXX"><Key algorithm="ecdsa"><PrivateKey format="pem">
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIPkqUSMK5bPQntppGeSsFcbXRcMWC2bx1lRpGaZEIrq/oAoGCCqGSM49
AwEHoUQDQgAEalaoKb/I5S9bpfDVzAYymLaJJowm59uojupRL/CY87KcCjeULbcB
QirzI2TcpH5ATmUc+qGtnyYwBaWSy0h7nQ==
-----END EC PRIVATE KEY-----
Here is sample cert-chain from "googlesamples
<https://github.com/googlesamples>/android-key-attestation
<https://github.com/googlesamples/android-key-attestation>"
https://github.com/googlesamples/android-key-attestation/blob/master/server/src/main/java/com/android/example/KeyAttestationExample.java
public static final String[] SAMPLE_ATTESTATION_CERT_CHAIN = new
String[]{ ATTESTATION_CERTIFICATE, INTERMEDIATE_CERTIFICATE,
ROOT_CERTIFICATE};
-----BEGIN CERTIFICATE-----
MIICizCCAjKgAwIBAgIJAKIFntEOQ1tXMAoGCCqGSM49BAMCMIGYMQswCQYDVQQGEw
JVUzETMBEG A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzE
VMBMGA1UECgwMR29vZ2xl LCBJbmMuMRAwDgYDVQQLDAdBbmRyb2lkMTMwMQYDVQQD
DCpBbmRyb2lkIEtleXN0b3JlIFNvZnR3 YXJlIEF0dGVzdGF0aW9uIFJvb3QwHhcNM
TYwMTExMDA0MzUwWhcNMzYwMTA2MDA0MzUwWjCBmDEL MAkGA1UEBhMCVVMxEzARBg
NVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcx FTATBgNVBAo
MDEdvb2dsZSwgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEzMDEGA1UEAwwqQW5kcm9p
ZCBLZXlzdG9yZSBTb2Z0d2FyZSBBdHRlc3RhdGlvbiBSb290MFkwEwYHKoZIzj0CAQ
YIKoZIzj0D AQcDQgAE7l1ex+HA220Dpn7mthvsTWpdamguD/9/SQ59dx9EIm29sa/
6FsvHrcV30lacqrewLVQB XT5DKyqO107sSHVBpKNjMGEwHQYDVR0OBBYEFMit6XdM
RcOjzw0WEOR5QzohWjDPMB8GA1UdIwQY MBaAFMit6XdMRcOjzw0WEOR5QzohWjDPM
A8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgKE MAoGCCqGSM49BAMCA0cAME
QCIDUho++LNEYenNVg8x1YiSBq3KNlQfYNns6KGYxmSGB7AiBNC/NR 2TB8fVvaNTQ
dqEcbY6WFZTytTySn502vQX3xvw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICeDCCAh6gAwIBAgICEAEwCgYIKoZIzj0EAwIwgZgxCzAJBgNVBAYTAlVTMRMwEQ
YDVQQIDApD YWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRUwEwYDVQQ
KDAxHb29nbGUsIEluYy4x EDAOBgNVBAsMB0FuZHJvaWQxMzAxBgNVBAMMKkFuZHJv
aWQgS2V5c3RvcmUgU29mdHdhcmUgQXR0 ZXN0YXRpb24gUm9vdDAeFw0xNjAxMTEwM
DQ2MDlaFw0yNjAxMDgwMDQ2MDlaMIGIMQswCQYDVQQG EwJVUzETMBEGA1UECAwKQ2
FsaWZvcm5pYTEVMBMGA1UECgwMR29vZ2xlLCBJbmMuMRAwDgYDVQQL DAdBbmRyb2l
kMTswOQYDVQQDDDJBbmRyb2lkIEtleXN0b3JlIFNvZnR3YXJlIEF0dGVzdGF0aW9u
IEludGVybWVkaWF0ZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOueefhCY1msyy
qRTImGzHCt kGaTgqlzJhP+rMv4ISdMIXSXSir+pblNf2bU4GUQZjW8U7ego6ZxWD7
bPhGuEBSjZjBkMB0GA1Ud DgQWBBQ//KzWGrE6noEguNUlHMVlux6RqTAfBgNVHSME
GDAWgBTIrel3TEXDo88NFhDkeUM6IVow zzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA
1UdDwEB/wQEAwIChDAKBggqhkjOPQQDAgNIADBFAiBL ipt77oK8wDOHri/AiZi03c
ONqycqRZ9pDMfDktQPjgIhAO7aAV229DLp1IQ7YkyUBO86fMy9Xvsi u+f+uXc/WT/
7
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIByTCCAXCgAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFBbmRyb2lkIE
tleW1hc3Rl cjAgFw03MDAxMDEwMDAwMDBaGA8yMTA2MDIwNzA2MjgxNVowGjEYMBY
GA1UEAwwPQSBLZXltYXN0 ZXIgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
FpsFUWID9p2QPAvtfal4MRf9vJg0tNc3 vKJwoDhhSCMm7If0FljgvmroBYQyCIbnn
Bxh2OU9SKxI/manPwIIUqOBojCBnzALBgNVHQ8EBAMC B4AwbwYKKwYBBAHWeQIBEQ
RhMF8CAQEKAQACAQEKAQEEBWhlbGxvBAAwDL+FPQgCBgFWDy29GDA6 oQUxAwIBAqI
DAgEDowQCAgEApQUxAwIBBKoDAgEBv4N4AwIBA7+DeQQCAgEsv4U+AwIBAL+FPwIF
ADAfBgNVHSMEGDAWgBQ//KzWGrE6noEguNUlHMVlux6RqTAKBggqhkjOPQQDAgNHAD
BEAiBKzJSk 9VNauKu4dr+ZJ5jMTNlAxSI99XkKEkXSolsGSAIgCnd5T99gv3B/IqM
CHn0yZ7Wuu/jisU0epRRo xh8otA8=
-----END CERTIFICATE-----

Post by 'Janis' via Android Security Discussions
Yes that is a perfectly viable. If you do not intend to use the Google
PlayStore you don't need a Google signed attestation key. Note, however,
that the attestation certificates issued by keymaster are checked by the
applications' service back ends. So if you allow apps from third parties
which use key attestation, their back ends may not trust your certificates
and reject the attestation certificates issued by your keymaster
implementation. You may need to negotiate with these vendors to white list
your CA. But if you control all of the apps it is up to you which CAs to
trust.

Post by d***@ff.com
Janis, thank you for the reply. Good to know that we don't have to use
Google root CA for CTS test.
Our platform doesn't allow application installation from Google
Playstore, which means all the Apps are controlled and signed by ourselves.
Can I assume that in this case these Apps can also use our own cert-chain
for Keymaster authority check?

Post by 'Janis' via Android Security Discussions
Hi,
CTS and VTS test do not check the origin of the root CA. So you can
pass these tests with a certificate chain rooted in a self signed CA. Once
you passed CTS and VTS you can get the Google signed keys. Please reach out
to your technical account manager at Google for the right process.
With kind regards,
Janis

Post by d***@ff.com
Get information from QCOM datasheet "Attestation key provision is
mandatory on new android O release, customer need do key attestation
before the CTS/VTS test. ", however, the information from Google is
we have to pass CTS before applying key attestation.
Which one is correct? Which department should we reach to to apply
the attestation key?

[d***@ff.com]

right, you use RSA-4k as root. How about expiration date of CA and leaf
certs, do you check that?
I notice your root is 10 yrs only. What's the plan for in field renewal on
the root? I think current attestation key provision is only for manufacture
environment.

Post by 'Janis' via Android Security Discussions
We usually have EC keys to attest to EC keys and RSA keys to attest to RSA
keys. And so are the intermediate certs. There is only one root CA cert
though for both chains. I would have to check back as to how strict this is
required. The key strength can vary. In the end it is important that the
chain can be verified.

Post by d***@ff.com
Thanks.
The existing CA-chain I am going to integrate this leaf attest cert is a
mix of RSA CA and ECC CA. Does Android O allow this? Otherwise I will have
to create a new chain which is ECC only.
Does Android O allow different key strength in the chain, for example, I
use ECC-521 for root, and 384 for intermediate and then 256 for leaf.
Is there any sample config file I can refer to, to generate the batch key
certificate?

Post by 'Janis' via Android Security Discussions
The keybox holds the private batch key. Batch keys are called "batch"
keys be cause they are used across a batch of at least 100K Android
devices. This is a privacy requirement.
Because of the batch nature of the attestation key it cannot be
generated in the TEE.
The keybox is very sensitive and you should only allow specially trained
personell to handle these and keep them tightly controlled, e.g, you don't
want to use the keybox posted above for anything but testing (I hope this
is obvious - just making sure). Also If you manage your own CA, you need to
manage your own revocation lists and revoke batch keys if you think they
have been compromised.
The chain consists of a root CA cert, one or more intermediate
certificates and a batch key certificate (I guess the example chain has 0
intermediates). The attestation certificate is at the end of this chain and
attests to a key generated in or imported into AndroidKeystore. It includes
the public key of the latter and a bunch of usage requirements, such as
purpose (SIGN, DECRYPT, ...), allowed digest and padding modes, whether
keys are authentication bound, or information about the root of trust (is
the bootloader locked ...). Checkout
https://source.android.com/security/keystore/attestation for a full
list of items that get attested to.

Post by d***@ff.com
What's the relation between keybox and attestation_cert_chain. Is
keybox the private key and the end-node "ATTESTATION_CERTIFICATE" of the
cert-chain is the certificate of that keybox?
Should the keybox key pair be generated inside TEE or generated from
external?
<Keybox DeviceID="XXXX"><Key algorithm="ecdsa"><PrivateKey
format="pem">
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIPkqUSMK5bPQntppGeSsFcbXRcMWC2bx1lRpGaZEIrq/oAoGCCqGSM49
AwEHoUQDQgAEalaoKb/I5S9bpfDVzAYymLaJJowm59uojupRL/CY87KcCjeULbcB
QirzI2TcpH5ATmUc+qGtnyYwBaWSy0h7nQ==
-----END EC PRIVATE KEY-----
Here is sample cert-chain from "googlesamples
<https://github.com/googlesamples>/android-key-attestation
<https://github.com/googlesamples/android-key-attestation>"
https://github.com/googlesamples/android-key-attestation/blob/master/server/src/main/java/com/android/example/KeyAttestationExample.java
public static final String[] SAMPLE_ATTESTATION_CERT_CHAIN = new
String[]{ ATTESTATION_CERTIFICATE, INTERMEDIATE_CERTIFICATE,
ROOT_CERTIFICATE};
-----BEGIN CERTIFICATE-----
MIICizCCAjKgAwIBAgIJAKIFntEOQ1tXMAoGCCqGSM49BAMCMIGYMQswCQYDVQQGEw
JVUzETMBEG A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzE
VMBMGA1UECgwMR29vZ2xl LCBJbmMuMRAwDgYDVQQLDAdBbmRyb2lkMTMwMQYDVQQD
DCpBbmRyb2lkIEtleXN0b3JlIFNvZnR3 YXJlIEF0dGVzdGF0aW9uIFJvb3QwHhcNM
TYwMTExMDA0MzUwWhcNMzYwMTA2MDA0MzUwWjCBmDEL MAkGA1UEBhMCVVMxEzARBg
NVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcx FTATBgNVBAo
MDEdvb2dsZSwgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEzMDEGA1UEAwwqQW5kcm9p
ZCBLZXlzdG9yZSBTb2Z0d2FyZSBBdHRlc3RhdGlvbiBSb290MFkwEwYHKoZIzj0CAQ
YIKoZIzj0D AQcDQgAE7l1ex+HA220Dpn7mthvsTWpdamguD/9/SQ59dx9EIm29sa/
6FsvHrcV30lacqrewLVQB XT5DKyqO107sSHVBpKNjMGEwHQYDVR0OBBYEFMit6XdM
RcOjzw0WEOR5QzohWjDPMB8GA1UdIwQY MBaAFMit6XdMRcOjzw0WEOR5QzohWjDPM
A8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgKE MAoGCCqGSM49BAMCA0cAME
QCIDUho++LNEYenNVg8x1YiSBq3KNlQfYNns6KGYxmSGB7AiBNC/NR 2TB8fVvaNTQ
dqEcbY6WFZTytTySn502vQX3xvw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICeDCCAh6gAwIBAgICEAEwCgYIKoZIzj0EAwIwgZgxCzAJBgNVBAYTAlVTMRMwEQ
YDVQQIDApD YWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRUwEwYDVQQ
KDAxHb29nbGUsIEluYy4x EDAOBgNVBAsMB0FuZHJvaWQxMzAxBgNVBAMMKkFuZHJv
aWQgS2V5c3RvcmUgU29mdHdhcmUgQXR0 ZXN0YXRpb24gUm9vdDAeFw0xNjAxMTEwM
DQ2MDlaFw0yNjAxMDgwMDQ2MDlaMIGIMQswCQYDVQQG EwJVUzETMBEGA1UECAwKQ2
FsaWZvcm5pYTEVMBMGA1UECgwMR29vZ2xlLCBJbmMuMRAwDgYDVQQL DAdBbmRyb2l
kMTswOQYDVQQDDDJBbmRyb2lkIEtleXN0b3JlIFNvZnR3YXJlIEF0dGVzdGF0aW9u
IEludGVybWVkaWF0ZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOueefhCY1msyy
qRTImGzHCt kGaTgqlzJhP+rMv4ISdMIXSXSir+pblNf2bU4GUQZjW8U7ego6ZxWD7
bPhGuEBSjZjBkMB0GA1Ud DgQWBBQ//KzWGrE6noEguNUlHMVlux6RqTAfBgNVHSME
GDAWgBTIrel3TEXDo88NFhDkeUM6IVow zzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA
1UdDwEB/wQEAwIChDAKBggqhkjOPQQDAgNIADBFAiBL ipt77oK8wDOHri/AiZi03c
ONqycqRZ9pDMfDktQPjgIhAO7aAV229DLp1IQ7YkyUBO86fMy9Xvsi u+f+uXc/WT/
7
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIByTCCAXCgAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFBbmRyb2lkIE
tleW1hc3Rl cjAgFw03MDAxMDEwMDAwMDBaGA8yMTA2MDIwNzA2MjgxNVowGjEYMBY
GA1UEAwwPQSBLZXltYXN0 ZXIgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
FpsFUWID9p2QPAvtfal4MRf9vJg0tNc3 vKJwoDhhSCMm7If0FljgvmroBYQyCIbnn
Bxh2OU9SKxI/manPwIIUqOBojCBnzALBgNVHQ8EBAMC B4AwbwYKKwYBBAHWeQIBEQ
RhMF8CAQEKAQACAQEKAQEEBWhlbGxvBAAwDL+FPQgCBgFWDy29GDA6 oQUxAwIBAqI
DAgEDowQCAgEApQUxAwIBBKoDAgEBv4N4AwIBA7+DeQQCAgEsv4U+AwIBAL+FPwIF
ADAfBgNVHSMEGDAWgBQ//KzWGrE6noEguNUlHMVlux6RqTAKBggqhkjOPQQDAgNHAD
BEAiBKzJSk 9VNauKu4dr+ZJ5jMTNlAxSI99XkKEkXSolsGSAIgCnd5T99gv3B/IqM
CHn0yZ7Wuu/jisU0epRRo xh8otA8=
-----END CERTIFICATE-----

Post by 'Janis' via Android Security Discussions
Yes that is a perfectly viable. If you do not intend to use the Google
PlayStore you don't need a Google signed attestation key. Note, however,
that the attestation certificates issued by keymaster are checked by the
applications' service back ends. So if you allow apps from third parties
which use key attestation, their back ends may not trust your certificates
and reject the attestation certificates issued by your keymaster
implementation. You may need to negotiate with these vendors to white list
your CA. But if you control all of the apps it is up to you which CAs to
trust.

Post by d***@ff.com
Janis, thank you for the reply. Good to know that we don't have to
use Google root CA for CTS test.
Our platform doesn't allow application installation from Google
Playstore, which means all the Apps are controlled and signed by ourselves.
Can I assume that in this case these Apps can also use our own cert-chain
for Keymaster authority check?

Post by 'Janis' via Android Security Discussions
Hi,
CTS and VTS test do not check the origin of the root CA. So you can
pass these tests with a certificate chain rooted in a self signed CA. Once
you passed CTS and VTS you can get the Google signed keys. Please reach out
to your technical account manager at Google for the right process.
With kind regards,
Janis

Post by d***@ff.com
Get information from QCOM datasheet "Attestation key provision is
mandatory on new android O release, customer need do key attestation
before the CTS/VTS test. ", however, the information from Google is
we have to pass CTS before applying key attestation.
Which one is correct? Which department should we reach to to apply
the attestation key?