Get desktop application:
View/edit binary Protocol Buffers messages
This enum is used by iOS devices as values for device_display_diagonal_mils in GcmDeviceInfo. There is no good way to calculate it on those devices.
This is the mils diagonal on an iPhone 5.
This is the mils diagonal on an iPad mini.
Type of curve
Used in:
Used by protocols between devices
the payload of the message
the sequence number of the message - must be increasing.
This should be kept in sync with DeviceType in: java/com/google/security/cryptauth/backend/services/common/common_enums.proto
Used in:
A convenience proto for encoding curve points in affine representation
Used in:
x and y are encoded in big-endian two's complement client MUST verify (x,y) is a valid point on the specified curve
Message used only during enrollment Field numbers should be kept in sync with DeviceInfo in: java/com/google/security/cryptauth/backend/services/common/common.proto
This field's name does not match the one in DeviceInfo for legacy reasons. Consider using long_device_id and device_type instead when enrolling non-android devices.
Used for device_address of DeviceInfo field 2, but for GCM capable devices.
Used for device_address of DeviceInfo field 2, but for iOS devices.
Does the user have notifications enabled for the given device address.
Used for device_address of DeviceInfo field 2, a Bluetooth Mac address for the device (e.g., to be used with EasyUnlock)
SHA-256 hash of the device master key (from the key exchange). Differs from DeviceInfo field 3, which contains the actual master key.
A SecureMessage.EcP256PublicKey
device's model name (e.g., an android.os.Build.MODEL or UIDevice.model)
device's locale
The handle for user_public_key (and implicitly, a master key)
The initial counter value for the device, sent by the device
The Operating System version on the device (e.g., an android.os.Build.DISPLAY or UIDevice.systemVersion)
The Operating System version number on the device (e.g., an android.os.Build.VERSION.SDK_INT)
The Operating System release on the device (e.g., an android.os.Build.VERSION.RELEASE)
The Operating System codename on the device (e.g., an android.os.Build.VERSION.CODENAME or UIDevice.systemName)
The software version running on the device (e.g., Authenticator app version string)
The software version number running on the device (e.g., Authenticator app version code)
Software package information if applicable (e.g., com.google.android.apps.authenticator2)
Size of the display in thousandths of an inch (e.g., 7000 mils = 7 in)
For Authzen capable devices, their Authzen protocol version
Not all devices have device identifiers that fit in 64 bits.
The device manufacturer name (e.g., android.os.Build.MANUFACTURER)
Used to indicate which type of device this is.
Is this device using a secure screenlock (e.g., pattern or pin unlock)
Is auto-unlocking the screenlock (e.g., when at "home") supported?
Is auto-unlocking the screenlock (e.g., when at "home") enabled?
Does the device have a Bluetooth (classic) radio?
Is the Bluetooth (classic) radio on?
Does the device hardware support a mobile data connection?
Does the device support tethering?
Does the device have a BLE radio?
Is the device a "Pixel Experience" Android device?
Is the device running in the ARC++ container on a chromebook?
Is the value set in |using_secure_screenlock| reliable? On some Android devices, the platform API to get the screenlock state is not trustworthy. See b/32212161.
A list of multi-device software features supported by the device.
A list of multi-device software features currently enabled (active) on the device.
The enrollment session id this is sent with
A copy of the user's OAuth token
sent as the first message from initiator to responder in an unauthenticated Diffie-Hellman Key Exchange
The session public key to send to the responder
The protocol version
A list of "reasons" that can be provided for calling server-side APIs. This is particularly important for calls that can be triggered by different kinds of events. Please try to keep reasons as generic as possible, so that codes can be re-used by various callers in a sensible fashion.
First run of the software package invoking this call
Ordinary periodic actions (e.g. monthly master key rotation)
Slow-cycle periodic action (e.g. yearly keypair rotation???)
Fast-cycle periodic action (e.g. daily sync for Smart Lock users)
Expired state (e.g. expired credentials, or cached entries) was detected
An unexpected protocol failure occurred (so attempting to repair state)
A new account has been added to the device
An existing account on the device has been changed
The user toggled the state of a feature (e.g. Smart Lock enabled via BT)
A "push" from the server caused this action (e.g. a sync tickle)
A local address change triggered this (e.g. GCM registration id changed)
A software update has triggered this
A manual action by the user triggered this (e.g. commands sent via adb)
A custom key has been invalidated on the device (e.g. screen lock is disabled).
Periodic action triggered by auth_proximity
Time at which the server received the login notification request.
Must correspond to user_id in LoginNotificationRequest, if set.
Host where the user's credentials were used to login, if meaningful.
Location from where the user's credentials were used, if meaningful.
Type of login, e.g. ssh, gnome-screensaver, or web.
sent inside the header of the first message from the responder to the initiator in an unauthenticated Diffie-Hellman Key Exchange
The session public key to send to the initiator
The protocol version
MultiDevice features which may be supported and enabled on a device. See
Used in:
Each flow in the protocol bumps this counter
Some (but not all) SPAKE flows send a point on an elliptic curve
Some (but not all) SPAKE flows send a hash value
The last flow of a SPAKE protocol can send an optional payload, since the key exchange is already complete on the sender's side.
Time after which this tickle should expire
Used in:
DEPRECATED (can be re-used after Aug 2015)
The kind of identity assertion generated by a "GCM V1" device (i.e., an Android phone that has registered with us a public and a symmetric key)
Device-to-device communications are protected by an unauthenticated Diffie-Hellman exchange. The InitiatorHello message is simply the initiator's public DH key, and is not encoded as a SecureMessage, so it doesn't have a tag. The ResponderHello message (which is sent by the responder to the initiator), on the other hand, carries a payload that is protected by the derived shared key. It also contains the responder's public DH key. ResponderHelloAndPayload messages have the DEVICE_TO_DEVICE_RESPONDER_HELLO tag.
Device-to-device communications are protected by an unauthenticated Diffie-Hellman exchange. Once the initiator and responder agree on a shared key (through Diffie-Hellman), they will use messages tagged with DEVICE_TO_DEVICE_MESSAGE to exchange data.
Notification to let a device know it should contact a nearby device.
Device-to-device communications are protected by an unauthenticated Diffie-Hellman exchange. During device-to-device authentication, the first message from initiator (the challenge) is signed and put into the payload of the message sent back to the initiator.
Specialty (corp only) features
Used in:
Framing errors
The message could not be deserialized
message_type has an undefined value
message_type received does not correspond to
expected type at this stage of the protocol
Could not deserialize message_data as per
ClientInit and ServerInit errors
version is invalid; server cannot find
suitable version to speak with client.
Random data is missing or of incorrect
length
No suitable handshake ciphers were found
The next protocol is missing, unknown, or
unsupported
The public key could not be parsed
Other errors
An internal error has occurred. error_message
public key matching selected handshake
highest supported version for rollback
protection
random bytes for replay/reuse protection
Next protocol that the client wants to speak.
One commitment (hash of ClientFinished containing public key) per supported cipher
Used in:
Used in:
,NIST P-256 used for ECDH, SHA512 used for
commitment
Curve 25519 used for ECDH, SHA512 used for
Identifies message type
Actual message, to be parsed according to
Used in:
highest supported version for rollback
protection
random bytes for replay/reuse protection
Selected Cipher and corresponding public key