platform_system_vold/Keymaster.h

139 lines
5.2 KiB
C
Raw Normal View History

/*
* Copyright (C) 2016 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.
*/
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
// TODO: Maybe "Keymaster" should be replaced with Keystore2 everywhere?
#ifndef ANDROID_VOLD_KEYMASTER_H
#define ANDROID_VOLD_KEYMASTER_H
#include "KeyBuffer.h"
#include <memory>
#include <string>
#include <utility>
#include <android-base/macros.h>
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
#include <keymint_support/authorization_set.h>
#include <keymint_support/keymint_tags.h>
#include <aidl/android/hardware/security/keymint/ErrorCode.h>
#include <aidl/android/system/keystore2/IKeystoreService.h>
#include <android/binder_manager.h>
namespace android {
namespace vold {
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
namespace ks2 = ::aidl::android::system::keystore2;
namespace km = ::aidl::android::hardware::security::keymint;
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
// C++ wrappers to the Keystore2 AIDL interface.
// This is tailored to the needs of KeyStorage, but could be extended to be
// a more general interface.
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
// Wrapper for a Keystore2 operation handle representing an
// ongoing Keystore2 operation. Aborts the operation
// in the destructor if it is unfinished. Methods log failures
// to LOG(ERROR).
class KeymasterOperation {
public:
~KeymasterOperation();
// Is this instance valid? This is false if creation fails, and becomes
// false on finish or if an update fails.
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
explicit operator bool() const { return (bool)ks2Operation; }
km::ErrorCode getErrorCode() const { return errorCode; }
std::optional<std::string> getUpgradedBlob() const { return upgradedBlob; }
// Call "update" repeatedly until all of the input is consumed, and
// concatenate the output. Return true on success.
template <class TI, class TO>
bool updateCompletely(TI& input, TO* output) {
if (output) output->clear();
return updateCompletely(input.data(), input.size(), [&](const char* b, size_t n) {
if (output) std::copy(b, b + n, std::back_inserter(*output));
});
}
// Finish and write the output to this string, unless pointer is null.
bool finish(std::string* output);
// Move constructor
KeymasterOperation(KeymasterOperation&& rhs) { *this = std::move(rhs); }
// Construct an object in an error state for error returns
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
KeymasterOperation() { errorCode = km::ErrorCode::UNKNOWN_ERROR; }
// Move Assignment
KeymasterOperation& operator=(KeymasterOperation&& rhs) {
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
ks2Operation = rhs.ks2Operation;
rhs.ks2Operation = nullptr;
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
upgradedBlob = rhs.upgradedBlob;
rhs.upgradedBlob = std::nullopt;
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
errorCode = rhs.errorCode;
rhs.errorCode = km::ErrorCode::UNKNOWN_ERROR;
return *this;
}
private:
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
KeymasterOperation(std::shared_ptr<ks2::IKeystoreOperation> ks2Op,
std::optional<std::vector<uint8_t>> blob)
: ks2Operation{ks2Op}, errorCode{km::ErrorCode::OK} {
if (blob)
upgradedBlob = std::optional(std::string(blob->begin(), blob->end()));
else
upgradedBlob = std::nullopt;
}
KeymasterOperation(km::ErrorCode errCode) : errorCode{errCode} {}
bool updateCompletely(const char* input, size_t inputLen,
const std::function<void(const char*, size_t)> consumer);
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
std::shared_ptr<ks2::IKeystoreOperation> ks2Operation;
std::optional<std::string> upgradedBlob;
km::ErrorCode errorCode;
DISALLOW_COPY_AND_ASSIGN(KeymasterOperation);
friend class Keymaster;
};
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
// Wrapper for keystore2 methods that vold uses.
class Keymaster {
public:
Keymaster();
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
// false if we failed to get a keystore2 security level.
explicit operator bool() { return (bool)securityLevel; }
// Generate a key using keystore2 from the given params.
bool generateKey(const km::AuthorizationSet& inParams, std::string* key);
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
// Exports a keystore2 key with STORAGE_KEY tag wrapped with a per-boot ephemeral key
bool exportKey(const KeyBuffer& kmKey, std::string* key);
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
// If supported, permanently delete a key from the keymint device it belongs to.
bool deleteKey(const std::string& key);
// Begin a new cryptographic operation, collecting output parameters if pointer is non-null
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
// If the key was upgraded as a result of a call to this method, the returned KeymasterOperation
// also stores the upgraded key blob.
KeymasterOperation begin(const std::string& key, const km::AuthorizationSet& inParams,
km::AuthorizationSet* outParams);
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
// Tell all Keymint devices that early boot has ended and early boot-only keys can no longer
// be created or used.
static void earlyBootEnded();
private:
Make vold use keystore2 instead of keymaster Make vold use keystore2 for all its operations instead of directly using keymaster. This way, we won't have any clients that bypass keystore2, and we'll no longer need to reserve a keymaster operation for vold. Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE) when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX. Keystore2 presents any SOFTWARE implementation as a TEE to callers when no "real" TEE is present. As far as storage encryption is concerned, there's no advantage to using a STRONGBOX when a "real" TEE is present, and a STRONGBOX can't be present if a "real" TEE isn't, so asking Keystore2 for a TEE is the best we can do in any situation. The difference in behaviour only really affects the full disk encryption code in cryptfs.cpp, which used to explicitly check that the keymaster device is a "real" TEE (as opposed to a SOFTWARE implementation) before using it (it can no longer do so since Keystore2 doesn't provide a way to do this). A little code history digging (7c49ab0a0b in particular) shows that cryptfs.cpp cared about two things when using a keymaster. - 1) that the keys generated by the keymaster were "standalone" keys - i.e. that the keymaster could operate on those keys without requiring /data or any other service to be available. - 2) that the keymaster was a non-SOFTWARE implementation so that things would still work in case a "real" TEE keymaster was ever somehow added to the device after first boot. Today, all "real" TEE keymasters always generate "standalone" keys, and a TEE has been required in Android devices since at least Android N. The only two exceptions are Goldfish and ARC++, which have SOFTWARE keymasters, but both those keymasters also generate "standalone" keys. We're also no longer worried about possibly adding a "real" TEE KM to either of those devices after first boot. So there's no longer a reason cryptfs.cpp can't use the SOFTWARE keymaster on those devices. There's also already an upgrade path in place (see test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's being used once a TEE keymaster is added to the device. So it's safe for cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it blindly, without checking whether or not it's a "real" TEE, which is why Keymaster::isSecure() just returns true now. A future patch will remove that function and simplify its callers. Bug: 181910578 Test: cuttlefish and bramble boot. Adding, switching between, stopping and removing users work. Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
2021-03-01 07:32:07 +01:00
std::shared_ptr<ks2::IKeystoreSecurityLevel> securityLevel;
DISALLOW_COPY_AND_ASSIGN(Keymaster);
};
} // namespace vold
} // namespace android
#endif