diff options
Diffstat (limited to 'docs/html/training')
| -rw-r--r-- | docs/html/training/articles/keystore.jd | 28 | ||||
| -rw-r--r-- | docs/html/training/wearables/data-layer/messages.jd | 12 |
2 files changed, 37 insertions, 3 deletions
diff --git a/docs/html/training/articles/keystore.jd b/docs/html/training/articles/keystore.jd index a4fc2d2..217db81 100644 --- a/docs/html/training/articles/keystore.jd +++ b/docs/html/training/articles/keystore.jd @@ -29,7 +29,9 @@ page.title=Android Keystore System <p>The Android Keystore system lets you store cryptographic keys in a container to make it more difficult to extract from the device. Once keys are in the keystore, they can be used for cryptographic operations with the key material - remaining non-exportable.</p> + remaining non-exportable. Moreover, it offers facilities to restrict when and + how keys can be used, such as requiring user authentication for key use or + restricting encryption keys to be used only in certain block modes.</p> <p>The Keystore system is used by the {@link android.security.KeyChain} API as well as the Android @@ -112,3 +114,27 @@ and {@link java.security.KeyPairGenerator} or <p>Similarly, verify data with the {@link java.security.Signature#verify(byte[])} method:</p> {@sample development/samples/ApiDemos/src/com/example/android/apis/security/KeyStoreUsage.java verify} + +<h3 id="UserAuthentication">Requiring User Authentication For Key Use</h3> + +<p>When generating or importing a key into the {@code AndroidKeyStore} you can specify that the key +can only be used if user has been authenticated. The user is authenticated using a subset of their +secure lock screen credentials. This is a security measure which makes it possible to generate +cryptographic assertions about the user having been authenticated. + +<p>When a key is configured to require user authentication, it is also configured to operate in one +of the two modes: +<ul> +<li>User authentication is valid for a duration of time. All keys in this mode are authorized + for use as soon as the user unlocks the secure lock screen or confirms their secure lock screen + credentials using the {@link android.app.KeyguardManager#createConfirmDeviceCredentialIntent(CharSequence, CharSequence) KeyguardManager.createConfirmDeviceCredentialIntent} + flow. Each key specifies for how long the authorization remains valid for that key. Such keys + can only be generated or imported if the secure lock screen is enabled (see {@link android.app.KeyguardManager#isKeyguardSecure Keyguard.isKeyguardSecure}). + These keys become permanently invalidated once the secure lock screen is disabled or forcibly + reset (e.g. by a Device Admin).</li> +<li>User authentication is required for every use of the key. In this mode, a specific operation + involving a specific key is authorized by the user. Currently, the only means of such + authorization is fingerprint authentication: {@link android.hardware.fingerprint.FingerprintManager#authenticate(CryptoObject, CancellationSignal, AuthenticationCallback, int) FingerprintManager.authenticate}. + Such keys can only be generated or imported if at least one fingerprint is enrolled (see {@link android.hardware.fingerprint.FingerprintManager#hasEnrolledFingerprints() FingerprintManager.hasEnrolledFingerprints}). + These keys become permanently invalidated once all fingerprints are unenrolled.</li> +</ul> diff --git a/docs/html/training/wearables/data-layer/messages.jd b/docs/html/training/wearables/data-layer/messages.jd index 043aff2..ef9bfb1 100644 --- a/docs/html/training/wearables/data-layer/messages.jd +++ b/docs/html/training/wearables/data-layer/messages.jd @@ -34,7 +34,7 @@ such as sending a message to the wearable to start an activity.</p> <p>Multiple wearable devices can be connected to a user’s handheld device. Each connected device in the network is considered a <em>node</em>. With multiple connected devices, you must consider which -nodes receive the messages. For example, In a voice transcription app that receives voice data on +nodes receive the messages. For example, in a voice transcription app that receives voice data on the wearable device, you should send the message to a node with the processing power and battery capacity to handle the request, such as a handheld device.</p> @@ -196,7 +196,15 @@ class.</p> <p>The following example shows how to send a message to the transcription-capable node from a wearable device. Verify that the node is available before you attempt to send the message. This call -is synchronous and blocks processing until the message is received or until the request times out. +is synchronous and blocks processing until the system queues the message for delivery. +</p> + +<p class="note"><strong>Note:</strong> A successful result code does not guarantee delivery of the +message. If your app requires data reliability, use +<a href="{@docRoot}reference/com/google/android/gms/wearable/DataItem.html"><code>DataItem</code></a> +objects or the +<a href="{@docRoot}reference/com/google/android/gms/wearable/ChannelApi.html"><code>ChannelApi</code></a> +class to send data between devices. </p> <pre> |