Due to my lack of knowledge in this matter I am facing some problems to identify which features are sign of a bad implementation of a symmetric authorization application.

As I am concerned the system must generate session keys using PRFs (Pseudorendom Functions) by the way of the master key(''MK') and a seed. Then this session keys will be used to encryption, decryption and authorization. Encryption and decryption keys('K1') have to be the same, nevertheless the authorization keys('K2') must never be the same as the keys used to confidentiality.

The 'MK' is never used in any task, only as a parameter to generate the session keys. All the keys (master and sessions) have to be securely stored inside of a specific HW. The 'MK' is specially delicate since if it is discovered all session keys will be threatened; however in case of one session key is being compromised the remaining keys will be still protected.(Q: Has to be 'MK' stored a long with the session keys or in a independent entity ? The target is a tag coupled to a reader, so I guess that the session keys has to be kept on both devices, but the 'MK' is stored apart form these entities, such as a secure PC or a trusted 3ยบ company. Are session keys generated on the tags or in a PC to then being placed inside ?)

Confidentiality :

To achieve the confidentiality feature the plain-text is usually chew by a cryptographic function or 'primitives', such as AES-128(Advanced Encryption Standard- 128 bit text) using 'K1'. AES-128 will encode texts of 128 bit length and if the text is shorter then it may be padded with a single '1' and successive '0's until 128 bit is reached.

When the text needs more than one crypt-block then this boxes are chained, having many variations or 'modes of operations'. CBC (cipher block chaining) is one of them and it has a IV(initialization vector) in order to give randomness to the first iterations. This IV must be different for each message, it will be attached to the plain-text(padded) before going thought the ciphering blocks, and usually has 128 bit length. (Q: How IV are generated? A randomized algorithm or something else? Can a IV be constructed using 'K2' on ECB(electronic codebook) mode of operation?)


To gain authenticity a MAC(message authentication code) is attached to the plain-text or codified-text (if confidentiality has been implemented) to send all the set afterwards. MACs are generated also using crypt-blocks but with few major differences, one example is the CBCMAC. The output is a single 128 bit data (unlike in the confidentiality part), 'K2' is used for the computations, the IV has to be a fixed value, usually '0', and always the input texts must have the same length; to avoid this last restriction OMAC1(knows also as CMAC) is usually used instead of CBCMAC.

The input data to generate the MAC must be the pre-encrypted text, not the plain-text. This procedure is know as E-than-MAC(Encrypt then MAC) and gives the best authentication features.(Q: I guess after generate the MAC and join it to the codified text the same session key has to be used to validate the MAC on the other side; Is it like 'decode' the MAC and make a Boolean comparison on the verification side ?)

  • $\begingroup$ Please ask one question per post. These questions are hardly related to each other. I'm closing this question for now, but feel free to copy the three parts into separate ones and post those as new questions. Note that you can include links to the other questions if you want. $\endgroup$ – Maarten Bodewes Apr 17 '19 at 15:40