AES256 CBC + HMAC SHA256 ensuring confidentiality *and* authentication?

Question

I'm thinking of using AES256 CBC + HMAC SHA-256 as a building block for messages that ensures both confidentiality and authentication.

In particular, consider this scenario:

• Alice is possession a public key belonging to Bob (the key exchange and algorithm is outside the scope of this question). Alice has an identifying key K, also shared with Bob, that she can use to identify herself with. Only Alice and Bob knows the key K.
• Alice encrypts (nonce || K) using Bob's public key.
• Bob decrypts the packet and has now has K and nonce.
• Bob uses SHA-256 with SHA256(K || nonce) to yield a K(e) of 256 bits.
• Bob uses SHA-256 with SHA256(K || nonce + 1) to yield a K(s) of 256 bits.

Now for every packet Bob wishes to send Alice he performs the following:

• Create a new random 128 bit IV
• Encrypts the message using the IV and K(e) as the key.
• Creates a SHA-256 HMAC with K(s) as key and (IV || Encrypted message) as data.
• Finally sends (IV || HMAC || Ciphertext) to Alice

Alice has also calculated K(e) and K(s), and follows the following procedure when receiving data from Bob:

• Split the message into IV, ciphertext and HMAC.
• Calculate the HMAC using K(s), IV and ciphertext.
• Compare HMAC with the HMAC sent. If this matches, Alice considers this message authenticated as a message sent by Bob, otherwise it is discarded.
• Alice decrypts the message using K(e)

Does this protocol ensure that Alice only decrypts messages from Bob, assuming that no one other than Bob can read the encrypted message that Alice sends him encrypted using his public key?

I.e. does messages constructed in this manner ensure both confidentiality and authentication?

Note: If the protocol requires Bob to send multiple messages, this scheme needs a slight modification to avoid replay attacks.

P.S. I am aware of AES-GCM/CCM, but this scheme would work with the basic AES, SHA and HMAC algorithms that are found in most crypto packages. This solution might also be slower, but that too is out of the scope for the question.

Answer 1

If you don't want to use PKI, take a look at TLS-PSK. It would seem to solve the exact problem you are solving yourself. See RFC 4279 (and 5487 for additional ciphersuites).