We discovered that public-key cryptosystems do not require a secure channel to exchange keys, unlike secret-key cryptosystems. However, most public-key cryptosystems (for example, RSA) are much slower than secret-key systems (e.g., AES). As a result, secret-key systems are typically used to encrypt "long" messages.
In this article, we will learn about the Bellare-Rogaway Scheme, a brief introduction to session key distribution, its security properties, and the assumptions made to achieve that security.
Session Key Distribution
Throughout session key distribution, an online Trusted Authority (TA) selects session keys and distributes them to network users via an interactive protocol when requested. A protocol of this type is known as a session key distribution scheme (SKDS). Session keys are often used to encrypt data for a set, relatively short period of time. The TA will encrypt the session keys using previously distributed secret keys, assuming that every network user holds a secret key for which the value is known to the TA.
In a session key distribution scheme, we know that the TA is assumed to have a shared secret key with each and every network user. KAlice represents Alice's secret key, KBob represents Bob's secret key, and so on. In a session key distribution scheme, the TA selects session keys and distributes them online in encrypted form upon network user request.
Bellare-Rogaway Scheme
In 1995, Bellare and Rogaway proposed a Session Key Distribution Scheme (SKDS) and provided proof of security under certain assumptions. Both Alice and Bob select random challenges that are sent to the TA. As a result, Bob is already involved in the scheme before the TA grants the session key. The following are the components of the TA's information to Alice:
A session key that has been encrypted with Alice's secret key.
A MAC tag based on the encrypted session key, Alice and Bob's identities, and Alice's challenge.
The data sent to Bob is analogous.
Bellare-Rogaway Scheme Protocol
The Bellare-Rogaway protocol is illustrated below:
Alice selects a random number, rA, and sends it to Bob along with ID(Alice), let's say A.
Bob selects a random number, rB, and sends the TA ID(Alice), ID(Bob), let’s say B, rA, and rB.
The TA selects a session key k at random. It then computes
yB = (EkB(k), MACB( A || B || rB || EkB(k) )), and
yA = (EkA(k), MACA( B || A || rA || EkA(k) )).
4. yB is sent to Bob, and yA is sent to Alice by the TA.
5. Alice uses her key KAlice to decrypt yA, yielding K. Bob decrypts yB with his key KBob, yielding K.
Protocol Analysis
This scheme does not include any key confirmation. When Alice accepts, she has yet to determine if Bob has accepted or even if Bob has received the TA's message. When Alice accepts, it simply means that she received the data she expected and that this information is correct, or, more precisely, that the tag is correct. From Alice's perspective, accepting implies that she has received a new session key from the TA. Furthermore, because this session key was encrypted with Alice's secret key, Alice is assured that no one else will be able to calculate the session key K from the data she just received.
Of course, Bob should have received a session key encryption as well. Alice is unaware of whether or not this occurred, but we will claim that Alice can be confident that nobody other than Bob can calculate the new session key. The analysis will be similar whenever the session is examined from Bob's point of view. In other words, the SKDS no longer has the goal of one-way or two-way key confirmation. This is replaced by the slightly weaker (but still useful) goal that, from the perspective of a scheme participant who "accepts," nobody other than their intended peer must be able to calculate the new session key.
Note:
Alice and Bob must ensure that the messages have the correct format, that the MAC is valid, and that the correct rA and rB values were used. The TA is authenticated to Alice and Bob using MACs in step 3. The protocol does not support authentication from Alice to Bob, or from Bob to Alice, or from Alice or Bob to the TA. It also does not support key confirmation from Alice to Bob or from Bob to Alice.
Bellare-Rogaway Protocol Security Properties and Assumptions
Let’s go through the security properties and their analysis of the Bellare-Rogaway Scheme.
If Alice, Bob, and the TA are truthful and the attacker is passive, Alice and Bob will calculate the same session key, K, and the attacker will not be able to compute any information about K.
If an (active) attacker modifies messages originating from (or being sent to) an honest participant, that participant will almost certainly "reject."
If Alice and the TA are truthful, and an (active) attacker impersonates Bob, the attacker will be unable to compute the session key.
If Bob and the TA are truthful, and an (active) attacker impersonates Alice, the attacker will be unable to compute the session key.
Thus, using a secure encryption scheme ensures the properties (1), (3), and (4). To demonstrate property (2), consider the likelihood that the attacker will guess the right new MAC or reuse a MAC from an earlier session
Thus to show security, certain assumptions are made to demonstrate security.
Alice and Bob are truthful.
rA, rB, and k are all chosen at random.
The encryption scheme and the MAC are both safe.
Only the intended owners have access to secret keys.
An online Trusted Authority (TA) selects session keys and distributes them to network users via an interactive protocol when requested.
What is the Bellare-Rogaway Scheme?
In 1995, Bellare and Rogaway proposed a Session Key Distribution Scheme (SKDS) and provided proof of security under certain assumptions. Both Alice and Bob select random challenges that are sent to the TA. As a result, Bob is already involved in the scheme before the TA grants the session key.
What are the security assumptions made for Bellare-Rogaway Scheme?
Alice and Bob are truthful, rA, rB, and k are all chosen randomly, the encryption scheme and the MAC are safe, and only the intended owners can access secret keys.
What is the disadvantage of the Bellare-Rogaway scheme?
The protocol does not support authentication from Alice to Bob, or from Bob to Alice, or from Alice or Bob to the TA. It also does not support key confirmation from Alice to Bob or Bob to Alice.
Conclusions
In this article, we have learned about the Bellare-Rogaway Scheme, a brief introduction to session key distribution and then its security properties and assumptions made to achieve that security.
Go through the below mentioned articles for a better understanding of cryptography: