93 lines
3.3 KiB
Java
Raw Normal View History

DevicePolicyManager: Add key generation functionality. This is the crux of the Verified Access feature implementation: Adding the ability to generate KeyChain keys directly by the secure hardware, rather than installing software-generated keys into KeyChain. Add generateKeyPair to the DevicePolicyManager, which delegates key generation (via the DevicePolicyManagerService) to the KeyChainService. Design highlights: * The key generation is delegated via the DevicePolicyManagerService to check that only authorized callers request key generation in KeyChain. * KeyChainService performs the actual key generation so it owns the key in Keystore outright. * DevicePolicyManagerService then grants the calling app access to the Keystore key, so it can actually be used. * Loading the public/private key pair, as well as attestation certificate chain, is done in the client code (DevicePolicyManager) to save parceling / unparceling those objects across process boundaries twice (for no good reason). NOTE: The key attestation functionality (that includes Device ID) is missing/untested. Will be added in a follow-up CL as this one is quite big already. HIGHLIGHT FOR REVIEWERS: * API: New API in DevicePolicyManager. Bug: 63388672 Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk) Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
2017-11-15 05:55:52 +00:00
/*
* Copyright (C) 2017 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package android.security;
import android.annotation.NonNull;
import android.annotation.Nullable;
DevicePolicyManager: Add key generation functionality. This is the crux of the Verified Access feature implementation: Adding the ability to generate KeyChain keys directly by the secure hardware, rather than installing software-generated keys into KeyChain. Add generateKeyPair to the DevicePolicyManager, which delegates key generation (via the DevicePolicyManagerService) to the KeyChainService. Design highlights: * The key generation is delegated via the DevicePolicyManagerService to check that only authorized callers request key generation in KeyChain. * KeyChainService performs the actual key generation so it owns the key in Keystore outright. * DevicePolicyManagerService then grants the calling app access to the Keystore key, so it can actually be used. * Loading the public/private key pair, as well as attestation certificate chain, is done in the client code (DevicePolicyManager) to save parceling / unparceling those objects across process boundaries twice (for no good reason). NOTE: The key attestation functionality (that includes Device ID) is missing/untested. Will be added in a follow-up CL as this one is quite big already. HIGHLIGHT FOR REVIEWERS: * API: New API in DevicePolicyManager. Bug: 63388672 Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk) Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
2017-11-15 05:55:52 +00:00
import java.security.KeyPair;
import java.security.cert.Certificate;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
DevicePolicyManager: Add key generation functionality. This is the crux of the Verified Access feature implementation: Adding the ability to generate KeyChain keys directly by the secure hardware, rather than installing software-generated keys into KeyChain. Add generateKeyPair to the DevicePolicyManager, which delegates key generation (via the DevicePolicyManagerService) to the KeyChainService. Design highlights: * The key generation is delegated via the DevicePolicyManagerService to check that only authorized callers request key generation in KeyChain. * KeyChainService performs the actual key generation so it owns the key in Keystore outright. * DevicePolicyManagerService then grants the calling app access to the Keystore key, so it can actually be used. * Loading the public/private key pair, as well as attestation certificate chain, is done in the client code (DevicePolicyManager) to save parceling / unparceling those objects across process boundaries twice (for no good reason). NOTE: The key attestation functionality (that includes Device ID) is missing/untested. Will be added in a follow-up CL as this one is quite big already. HIGHLIGHT FOR REVIEWERS: * API: New API in DevicePolicyManager. Bug: 63388672 Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk) Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
2017-11-15 05:55:52 +00:00
import java.util.List;
/**
* The {@code AttestedKeyPair} class contains a {@code KeyPair} instance of
* keys generated by Keystore and owned by KeyChain, as well as an attestation
* record for the key.
*
* <p>Such keys can be obtained by calling
* {@link android.app.admin.DevicePolicyManager#generateKeyPair}.
*/
public final class AttestedKeyPair {
private final KeyPair mKeyPair;
private final List<Certificate> mAttestationRecord;
DevicePolicyManager: Add key generation functionality. This is the crux of the Verified Access feature implementation: Adding the ability to generate KeyChain keys directly by the secure hardware, rather than installing software-generated keys into KeyChain. Add generateKeyPair to the DevicePolicyManager, which delegates key generation (via the DevicePolicyManagerService) to the KeyChainService. Design highlights: * The key generation is delegated via the DevicePolicyManagerService to check that only authorized callers request key generation in KeyChain. * KeyChainService performs the actual key generation so it owns the key in Keystore outright. * DevicePolicyManagerService then grants the calling app access to the Keystore key, so it can actually be used. * Loading the public/private key pair, as well as attestation certificate chain, is done in the client code (DevicePolicyManager) to save parceling / unparceling those objects across process boundaries twice (for no good reason). NOTE: The key attestation functionality (that includes Device ID) is missing/untested. Will be added in a follow-up CL as this one is quite big already. HIGHLIGHT FOR REVIEWERS: * API: New API in DevicePolicyManager. Bug: 63388672 Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk) Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
2017-11-15 05:55:52 +00:00
/**
* Public constructor for creating a new instance (useful for testing).
*
* @param keyPair the key pair associated with the attestation record.
* @param attestationRecord attestation record for the provided key pair.
DevicePolicyManager: Add key generation functionality. This is the crux of the Verified Access feature implementation: Adding the ability to generate KeyChain keys directly by the secure hardware, rather than installing software-generated keys into KeyChain. Add generateKeyPair to the DevicePolicyManager, which delegates key generation (via the DevicePolicyManagerService) to the KeyChainService. Design highlights: * The key generation is delegated via the DevicePolicyManagerService to check that only authorized callers request key generation in KeyChain. * KeyChainService performs the actual key generation so it owns the key in Keystore outright. * DevicePolicyManagerService then grants the calling app access to the Keystore key, so it can actually be used. * Loading the public/private key pair, as well as attestation certificate chain, is done in the client code (DevicePolicyManager) to save parceling / unparceling those objects across process boundaries twice (for no good reason). NOTE: The key attestation functionality (that includes Device ID) is missing/untested. Will be added in a follow-up CL as this one is quite big already. HIGHLIGHT FOR REVIEWERS: * API: New API in DevicePolicyManager. Bug: 63388672 Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk) Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
2017-11-15 05:55:52 +00:00
*/
public AttestedKeyPair(
@Nullable KeyPair keyPair, @NonNull List<Certificate> attestationRecord) {
DevicePolicyManager: Add key generation functionality. This is the crux of the Verified Access feature implementation: Adding the ability to generate KeyChain keys directly by the secure hardware, rather than installing software-generated keys into KeyChain. Add generateKeyPair to the DevicePolicyManager, which delegates key generation (via the DevicePolicyManagerService) to the KeyChainService. Design highlights: * The key generation is delegated via the DevicePolicyManagerService to check that only authorized callers request key generation in KeyChain. * KeyChainService performs the actual key generation so it owns the key in Keystore outright. * DevicePolicyManagerService then grants the calling app access to the Keystore key, so it can actually be used. * Loading the public/private key pair, as well as attestation certificate chain, is done in the client code (DevicePolicyManager) to save parceling / unparceling those objects across process boundaries twice (for no good reason). NOTE: The key attestation functionality (that includes Device ID) is missing/untested. Will be added in a follow-up CL as this one is quite big already. HIGHLIGHT FOR REVIEWERS: * API: New API in DevicePolicyManager. Bug: 63388672 Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk) Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
2017-11-15 05:55:52 +00:00
mKeyPair = keyPair;
mAttestationRecord = attestationRecord;
}
/**
* @hide used by platform.
*/
public AttestedKeyPair(@Nullable KeyPair keyPair, @Nullable Certificate[] attestationRecord) {
mKeyPair = keyPair;
if (attestationRecord == null) {
mAttestationRecord = new ArrayList();
} else {
mAttestationRecord = Arrays.asList(attestationRecord);
}
}
DevicePolicyManager: Add key generation functionality. This is the crux of the Verified Access feature implementation: Adding the ability to generate KeyChain keys directly by the secure hardware, rather than installing software-generated keys into KeyChain. Add generateKeyPair to the DevicePolicyManager, which delegates key generation (via the DevicePolicyManagerService) to the KeyChainService. Design highlights: * The key generation is delegated via the DevicePolicyManagerService to check that only authorized callers request key generation in KeyChain. * KeyChainService performs the actual key generation so it owns the key in Keystore outright. * DevicePolicyManagerService then grants the calling app access to the Keystore key, so it can actually be used. * Loading the public/private key pair, as well as attestation certificate chain, is done in the client code (DevicePolicyManager) to save parceling / unparceling those objects across process boundaries twice (for no good reason). NOTE: The key attestation functionality (that includes Device ID) is missing/untested. Will be added in a follow-up CL as this one is quite big already. HIGHLIGHT FOR REVIEWERS: * API: New API in DevicePolicyManager. Bug: 63388672 Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk) Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
2017-11-15 05:55:52 +00:00
/**
* Returns the generated key pair associated with the attestation record
* in this instance.
*/
public @Nullable KeyPair getKeyPair() {
DevicePolicyManager: Add key generation functionality. This is the crux of the Verified Access feature implementation: Adding the ability to generate KeyChain keys directly by the secure hardware, rather than installing software-generated keys into KeyChain. Add generateKeyPair to the DevicePolicyManager, which delegates key generation (via the DevicePolicyManagerService) to the KeyChainService. Design highlights: * The key generation is delegated via the DevicePolicyManagerService to check that only authorized callers request key generation in KeyChain. * KeyChainService performs the actual key generation so it owns the key in Keystore outright. * DevicePolicyManagerService then grants the calling app access to the Keystore key, so it can actually be used. * Loading the public/private key pair, as well as attestation certificate chain, is done in the client code (DevicePolicyManager) to save parceling / unparceling those objects across process boundaries twice (for no good reason). NOTE: The key attestation functionality (that includes Device ID) is missing/untested. Will be added in a follow-up CL as this one is quite big already. HIGHLIGHT FOR REVIEWERS: * API: New API in DevicePolicyManager. Bug: 63388672 Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk) Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
2017-11-15 05:55:52 +00:00
return mKeyPair;
}
/**
* Returns the attestation record for the key pair in this instance.
*
* The attestation record is a chain of certificates. The leaf certificate links to the public
* key of this key pair and other properties of the key or the device. If the key is in secure
* hardware, and if the secure hardware supports attestation, the leaf certificate will be
* signed by a chain of certificates rooted at a trustworthy CA key. Otherwise the chain will be
* rooted at an untrusted certificate.
*
* The attestation record could be for properties of the key, or include device identifiers.
*
* See {@link android.security.keystore.KeyGenParameterSpec.Builder#setAttestationChallenge}
* and <a href="https://developer.android.com/training/articles/security-key-attestation.html">
* Key Attestation</a> for the format of the attestation record inside the certificate.
*/
public @NonNull List<Certificate> getAttestationRecord() {
return Collections.unmodifiableList(mAttestationRecord);
DevicePolicyManager: Add key generation functionality. This is the crux of the Verified Access feature implementation: Adding the ability to generate KeyChain keys directly by the secure hardware, rather than installing software-generated keys into KeyChain. Add generateKeyPair to the DevicePolicyManager, which delegates key generation (via the DevicePolicyManagerService) to the KeyChainService. Design highlights: * The key generation is delegated via the DevicePolicyManagerService to check that only authorized callers request key generation in KeyChain. * KeyChainService performs the actual key generation so it owns the key in Keystore outright. * DevicePolicyManagerService then grants the calling app access to the Keystore key, so it can actually be used. * Loading the public/private key pair, as well as attestation certificate chain, is done in the client code (DevicePolicyManager) to save parceling / unparceling those objects across process boundaries twice (for no good reason). NOTE: The key attestation functionality (that includes Device ID) is missing/untested. Will be added in a follow-up CL as this one is quite big already. HIGHLIGHT FOR REVIEWERS: * API: New API in DevicePolicyManager. Bug: 63388672 Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk) Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
2017-11-15 05:55:52 +00:00
}
}