Skip Navigation
  1. BlackBerry Docs
  2. BBM Enterprise
  3. BBM Enterprise security note
  4. How BBM Enterprise protects messages
  5. BBM Enterprise key usage
  6. Key exchange process
  7. Parameters that the BBM Enterprise key exchange uses

Parameters that the
BBM Enterprise
 key exchange uses

The description of the
BBM Enterprise
 key exchange uses the following labels:
Parameter
Description
A, B
The two key exchange participants (A initiator, B recipient)
X
A
, X
B
Versions of X belonging to A and B
PIN
AB
BlackBerry
 PIN value for A and B
Version
AB
The highest supported protocol version by each party
S
AB
Public portion of EC-SPEKE exchange values
S'
AB
Private portion of EC-SPEKE exchange values
Ksign
AB
Public portion of signing key
K'sign
AB
Private portion of signing key
Kenc
AB
Public portion of encryption key
K'enc
AB
Private portion of encryption key
K
enc
Symmetric encryption key protecting the confidentiality of the key exchange
K
mac
Symmetric key protecting the integrity of the key exchange
nonce
Initialization Vector nonce associated with encryption using K
enc
ENCMAC {K
enc
, K
mac
, IV} (data)
Symmetric encryption with K
enc
 followed by the addition of a MAC of the ciphertext with K
mac
DECMAC {K
enc
, K
mac
, IV} (data)
The inverse of ENCMAC: verification of the MAC with K
mac
, followed by decryption of the authenticated ciphertext using K
enc
KDF (aux, secret)
A standard KDF function
EC-SPEKE-GEN (secret)
Generates a non-deterministic key pair based on a shared secret
EC-DH (private, public)
Generates a raw shared secret with ECDH
EC-GEN ()
Generates a new random Elliptic Curve key pair
K
proof
A symmetric key used for proving possession of the private key
EC-SIGN {secret} (data)
A public key signature on a hash using ECDSA
MAC {secret} (data)
Calculates a MAC keyed with secret on data
T3, T4
Message authentication tags for messages #3 and #4
SS
AB
The EC-SPEKE shared secret value between A and B
F
The prefix value used for cryptographic separation between usages of the same key between different
BBM
 applications, protocol versions, and sessions
S
Shared secrets, shared in-band out-of-band (for details, see Key exchange process)
||
Indicates concatenation
(X, Y)
Indicates separation of concatenated values

Data flow: Detailed
BBM Enterprise
 key exchange process

  1. Each device generates a long-lived encryption key pair and a signing key pair.
    1. The initiator’s device generates:
      (Ksign
      A
      , K'sign
      A
      ) = EC-GEN ()
(Kenc
      A
      , K'enc
      A
      ) = EC-GEN ()
    2. The recipient’s device generates:
      (Ksign
      B
      , K'sign
      B
      ) = EC-GEN ()
(Kenc
      B
      , K'enc
      B
      ) = EC-GEN ()
  2. The initiator chooses or autogenerates a secret password. This shared password is sent automatically in-band or is sent manually out-of-band to the recipient using an SMS text message, email, phone call, or in person. For details, see Key exchange process.
  3. The initiator sends the first
    BBM
     message, which is an invitation that contains the initiator's contact information and the highest version of
    BBM Enterprise
     that they support.
    Version = 0
p = KDF ("EC-SPEKE Password", F || S), forget S, where sizeof(p) = 256 bits
(S
    A
    , S'
    A
    ) = EC-SPEKE-GEN (p), forget p
invite_id = 64-bit nonce
    The initiator’s invitation message (Message #1) is: (Version
    A
    , invite_id, PIN
    A
    , S
    A
    )
  4. The recipient responds to the invitation and provides the highest version of
    BBM Enterprise
     that the recipient supports, proof that they know the secret password, and the recipient's long-lived public encryption and signing keys.
    Version = 0
p = KDF ("EC-SPEKE Password", F || S), forget S, where sizeof(p) = 256 bits
(S
    B
    , S'
    B
    ) = EC-SPEKE-GEN (p), forget p
Version = MIN (Version
    A
    , Version
    B
    )
SS
    AB
     = EC-DH (S'
    B
    , S
    A
    )
(K
    enc
    , K
    mac
    , nonce) = KDF ("BBM Enterprise Key Exchange", F || SS
    AB
    )
Message #2 payload = P2 = (invite_id, Ksign
    B
    , Kenc
    B
    )
Message #2 payload signature = S2 = EC-SIGN {K'sign
    B
    } (F || version
    B
     || P2 || S
    A
     || S
    B
    )
Message #2 encrypted payload = E2 = ENCMAC {K
    enc
    , K
    mac
    , nonce} (P2 || S2)
    The recipient’s response message (Message #2) is: (Version
    B
    , S
    B
    , E2)
  5. The initiator responds to the acceptance and provides proof that they know the secret password, the initiator's long-lived public encryption and signing keys, and proof that the initiator's private keys correspond to the public keys that the initiator claims to own.
    Version = MIN (VersionA, VersionB)
Increment password_attempts.
If (password_attempts > 5) then abort.
SS
    AB
     = EC-DH (S'_A, S_B)
(K
    enc
    , K
    mac
    , nonce) = KDF ("BBM Enterprise Key Exchange", F || SS
    AB
    )
(P2, S2) = DECMAC {K
    enc
    , K
    mac
    , nonce} (E2)
(Ksign_B,Kenc_B) = P2
Verify signature S2.
Kenc
    AB
     = EC-DH (K'enc
    A
    , Kenc
    B
    )
K
    proof
     = KDF ("K_proof", F || Kenc
    AB
    ), where sizeof(K
    proof
    ) = 256 bits
Message #3 Auth Tag = T3 = MAC {K
    proof
    } (F || Ksign
    B
    || Kenc
    B
    )
Message #3 payload = P3 = (Ksign
    A
    , Kenc
    A
    , T3)
Message #3 payload signature = S3 = EC-SIGN {K'sign
    A
    } (F || P3 || S
    B
     || S
    A
     || Ksign
    B
     || Kenc
    B
    )
Message #3 encrypted payload = E3 = ENCMAC {K
    enc
    , K
    mac
    , nonce}(P3 || S3)
    The initiator’s response message (Message #3) is: E3
  6. The recipient responds with proof that they own the recipient's private keys.
    (P3, S3) = DECMAC {K
    enc
    , K
    mac
    , nonce} (E3)
(Ksign
    A
    , Kenc
    A
    , T3') = P3
Verify signature S3.
Kenc
    AB
     = EC-DH (K'enc_B, Kenc
    A
    )
Kproof' = KDF ("K_proof", F || Kenc
    AB
    ), where sizeof (K
    proof
    ) = 256 bits
T3 = MAC {K
    proof
    '} (F || Ksign
    B
     || Kenc
    B
    )
Check T3 == T3'
Message #4 Auth Tag = T4 = MAC {K
    proof
    '}(F || Ksign
    A
     || Kenc
    A
    )
E4 = ENCMAC {K
    enc
    , K
    mac
    , nonce} (T4)
    The initiator’s response message (Message #4) is: E4
  7. After the initiator verifies the final message from the recipient, each party knows the other’s public keys and that they belong to someone who knows both the associated private keys and the secret password.
    T4' = DECMAC {K
    enc
    , K
    mac
    , nonce} (Message #4)
Check T4' against MAC {K
    proof
    } (F || Ksign
    A
     || Kenc
    A
    )
After the key exchange is completed, the security of messages no longer depends on the secrecy of the passphrase or the ephemeral key pairs. The public keys for encryption and signing are stored for each contact and the contact is confirmed as the owner of the private keys.