This expands get, getmtime, exportKey, getKeyCharacteristcs and begin to
accept a uid to run as. This is only for system to use keys owned by
Wifi and VPN, and not something that can be used to do operations as
another arbitrary application.
Cherry-picked from 5bbf04803f
Bug: 23978113
Change-Id: I06aa089859edc934a5415e3b184b917d6d171ae2
When getting trust anchors we need to dedup them based on the
certificate to avoid having multiple trust anchors with the same cert
but different pin override behavior. If there are multiple trust anchors
with the same cert, the trust anchor which overrides pins wins.
Change-Id: Ida31f2551f56997418b8b091bb2598c5593cb069
Debug overrides are only used if the application is debuggable in
order to help local debugging and development by trusting additional
CAs. In a non-debuggable version of the application the debug-overrides
are ignored.
Trust anchors in the debug override configuration have two key
differences from those in base-config and domain-config:
1) trust anchors in the debug-overrides are trusted for all connections
in addition to any trust anchors included in the relevant base/domain
configs.
2) By default trust anchors in the debug config override pins, as their
purpose is for connecting to non-standard servers for debugging and
testing and those servers should not be pinned in the production
configuration.
Change-Id: I15ee98eae182be0ffaa49b06bc5e1c6c3d22baee
Nested domain-config inherit unset parameters from the domain-config
they are nested in. This helps avoid copy and pasted configs that are
almost the same except a few minor differences for a domain with
slightly different requirements.
For example: Consider a domain-config for example.com that, among other
settings, does not enforce hsts. Now if you want the rules for
example.com to apply to secure.example.com except that hsts _is_
enforced you can make a nested domain-config for secure.example.com
under example.com that sets hstsEnforced="true" and nothing else.
Change-Id: I9e33f7e62127fd7f4f15c3560fff2f2626477bd4
XmlConfigSource parses an ApplicationConfig from an xml resource.
Currently this supports app-wide default configuration via the
base-config element, per domain via the domain-config element and
inheritance of unset properties at parse time.
Inheritance of unset properties is currently only:
domain-config -> base-config -> platform default configuration
Where the most specific value is used.
For example: If the base-config specifies trust anchors, all connections
will use those anchors except for connections to a domain which has a
domain-config that specifies trust anchors, in which case the
domain-config's trust anchors will be used. If the domain-config or
base-config don't set trust anchors, or don't exist, then the platform
default trust anchors will be used.
Nested domain-config entries, debug-overrides, and thorough
documentation of the xml format will follow in later commits.
Change-Id: I1232ff1e8079a81b340bc12e142f0889f6947aa0
If the user has not added any CAs to the user trust store the user-added
directory will not have been created.
Change-Id: I8b5f73af3c0761c56969874231004fedbf7badda
The builder supports all the standard builder set* methods as well as
setting a parent builder to use when values are not set (recursively).
This allows us to have a level of inheretence in configurations without
complicating the lookup and trust checking logic by doing inheretence
when building the configs.
Change-Id: I054af83451e52761227479eadf9cb9803437505f
Initial implementation of a unified application wide static
network security configuration.
This currently encompases:
* Trust decisions such as what trust anchors to use as well as static
certificate pinning.
* Policy on what to do with cleartext traffic.
In order to prevent issues due to interplay of various components in an
application and their potentially different security requirements
configuration can be specified at a per-domain granularity in addition
to application wide defaults.
This change contains the internal data structures and trust management
code, hooking these up in application startup will come in a future
commit.
Change-Id: I53ce5ba510a4221d58839e61713262a8f4c6699c
This makes Android Keystore add the KM_MIN_MAC_LENGTH tag to generated
and imported HMAC and AES-GCM keys. This tag specifies the minimum
length of the MAC/authentication tag authorized to be used for the
key.
For HMAC keys the minimum MAC length is set to the length of the
digest associated with the key (HMAC keys are authorized for exactly
one digest). For AES keys the minimum authetication tag length is set
to 96 bit. This is the minimum supported by Android Keystore's AES-GCM
implementation.
Bug: 22337277
Change-Id: Ic6e47cf084734d1592788dc58088889f7fff74eb
This CL ensures that Android Keystore framework code complies with
signedness of keymaster tags. In particular:
* INT tags are unsigned 32-bit numbers, and
* LONG and DATE tags are unsigned 64-bit numbers.
The ensure compliance, KeymasterArguments and KeyCharacteristics
classes through which Android Keystore interacts with Keymaster tags
have been modified as follows:
* ENUM and INT tags which used to be conflated are now added/queried
via separate methods, because ENUM can remain represented as an int
data type whereas INT is now represented as a long data type with
permitted range being [0; 2^32).
* Methods for adding/quering LONG tags have been switched from the long
data type to the BigInteger data type and now ensure that the value
is in the permitted [0; 2^63).
* Methods for adding/querying DATE tags now ensure the Date value is
in the permitted range [0; 2^63) ms since Unix epoch.
* Methods for adding tags throw an IllegalArgumentException if the tag
type is unsuitable for the method. This is to ensure that tags with
invalid values cannot be added through similar methods (e.g., INT tag
added via an ENUM tag addition method invoked with a negative value).
Bug: 22008538
Change-Id: I6eefd5cbb561cc52d27de952691af4d9d5e1af1e
This CL makes Android Keystore framework code add
KM_TAG_ACTIVE_DATETIME, KM_TAG_ORIGINATION_EXPIRE_DATETIME, and
KM_TAG_USAGE_EXPIRE_DATETIME tags to the authorizations set only
if the corresponding time instants were specified through the
framework-level API. This is fine because these tags are optional as
it turns out.
Bug: 18088752
Change-Id: I6a5ae4cadb441e61576231815e6bec6e9248bc72
This reflects the changes in da89dde9787dfbd8c053119ab52d9e671106b18e
in system/keymaster.
Bug: 19919114
Change-Id: I9cdfc7ce63099c4de29029b1fc112369c4a68eba
If provided the extra entropy will be added to the device before calling
finish. If entropy is provided and the device does not support supplying
additional entropy then finish will fail with KM_ERROR_UNIMPLEMENTED.
(cherry-picked from commit 9ce30624a4)
Change-Id: If26be118bf382604f6f8e96e833b76e6f9e94d58
Output parameters are gone from begin, instead they will returned in the
OperationResult and begin, update, and finish may return output
parameters.
Change-Id: I072afeb6c65f6c512b40603824c25686ac44e7c8
Rename confusingly named methods, add userID arguments to all methods
that operate on user state and delete methods that have been replaced by
the onUser* methods.
Some of the old methods have been kept in KeyStore.java in order to ease
the transition of various system packages to the new methods.
(cherry-picked from commit d8aacca3a1)
Change-Id: Ic271689d62c36d255c5adee26c7abc2e7ed24df5
Add KeyStore.onUserPasswordChanged for the lockscreen to call when
the user changes their password. Keystore will then handle the logic of
deleting keys. Instead of calling Keystore.password_uid for both
unlocking and password changes the behavior has been split into
Keystore.unlock and onUserPasswordChanged.
Change-Id: I324914c00195d762cbaa8c63084e41fa796b7df8
This converts KM_ERROR_CALLER_NONCE_PROHIBITED into
InvalidAlgorithmParameterSpec, as expected by the contract of JCA
Cipher.
Bug: 18088752
Change-Id: I6a01e2d7118c478b27a0d7a5a14a127de8913755
This enables users of AndroidKeyStore crypto to differentiate between
the key being unusable until the user is authenticated
(UserNotAuthenticatedException) and the key being permanently unusable
(KeyPermanentlyInvalidatedException). The latter is the case when the
secure lock screen has been disabled or reset, and, for keys that
require user authentication for every use, when a new fingerprint is
enrolled or all fingerprints are unenrolled.
NOTE: The KeyPermanentlyInvalidatedException subsumes/replaces the
NewFingerprintEnrolledException which has thus been removed. There
is no way to find out whether a key was permenently invalidated
specifically because a new fingerprint was added.
Bug: 20642549
Bug: 20526234
Change-Id: I0206cd99eef5c605c9c4d6afc5eea02eb3b1fe6b
This simplifies the AndroidKeyStore API around user authentication: no
more explicit control over which user authenticators are bound to
which keys.
User-authenticated keys with timeout are unlocked by whatever unlocks
the secure lock screen (currently, password/PIN/pattern or
fingerprint). User-authenticated keys that need authentication for
every use are unlocked by fingerprint only.
Bug: 20526234
Bug: 20642549
Change-Id: I1e5e6c988f32657d820797ad5696797477a9ebe9
This updates the documentation of the application element of
AndroidManifest.xml to mention the new android:usesCleartextTraffic
attribute.
This also updates the Javadoc of
android.security.NetworkSecurityPolicy and ApplicationInfo to match.
Bug: 19215516
Change-Id: I5c221b56addae8988b4db51994d18ae379d0fbe3
This replaces int-based enums from KeyStoreKeyConstraints with
String values commonly used in JCA API.
As part of under the hood refactoring:
* KeyStoreKeyCharacteristics and KeyStoreKeyConstraints have been
merged into KeyStoreKeyProperties.
* KeymasterUtils methods operating on KeymasterArguments and
KeymasterCharacteristics have been moved to their respective
classes.
Bug: 18088752
Change-Id: I9c8b984cb3c28184adb617e34d87f2837bd1d3a1
