| поискавой системы для электроныых деталей |
|
MF1P2131DA4/02 датащи(PDF) 17 Page - NXP Semiconductors |
|
|
|||||||||||||||||||||||||||||
MF1P2131DA4/02 датащи(HTML) 17 Page - NXP Semiconductors |
|
17 / 33 page ![]() NXP Semiconductors MF1P(H)x1y1 MIFARE Plus EV1 MF1P(H)x1y1 All information provided in this document is subject to legal disclaimers. © NXP B.V. 2019. All rights reserved. Product short data sheet Rev. 3.2 — 6 December 2018 COMPANY PUBLIC 366932 17 / 33 8.10 Security level 3 The operation in security level 3 is solely based on the ISO/IEC 14443-4 protocol layer. The usage of the backwards compatibility protocol is not possible. In security level 3, a mandatory AES authentication between PICC and reader is conducted, where two keys are generated as a function of the random numbers from the PICC and the reader as well as of the shared key. These two session keys are used to secure the data which is exchanged on the interface between the card and reader. One of the two keys is used to ensure the confidentiality of the command and the response while the other key ensures the integrity of the command and the response. MIFARE Plus EV1 features the secure messaging from its predecessor MIFARE Plus EV0 and it offers the possibility to choose the newly introduced EV1 secure messaging. On First Authenticate, the PCD can use the PCD capability bytes to chose between MIFARE Plus EV0 and MIFARE Plus EV1 secure messaging. The reader can decide which security needs to be used in the communication between PICC and reader. In the simplest case, all commands are secured by a MAC, such that the PICC will only accept commands from the authenticated reader. Any message tampering is detected by verifying the MAC. All responses are appended by a MAC to prove to the reader that neither the command nor the response have been compromised. If performance is the highest priority, the card can be configured to omit the MAC for read commands. The card then accepts read commands without knowing whether they are authentic. However, there is a mechanism to prove to the reader that the read response is resulting from the unmodified read command that it sent. Other commands, like write commands, always need to have a MAC appended to ensure that no memory changes are carried out without proving the authenticity of the command. The reader can decide for each command whether a MAC is included in the response. When the appropriate MAC is received, due to linked MACs the reader knows that the command and commands before it were properly executed. All commands between two consecutive First Authenticate commands belong to one transaction and the MACing mechanism assures integrity of the whole transaction. If the MAC on read responses is omitted, the integrity of all read responses within one session can still be verified by including a MAC on one read response before issuing the next First or Following Authenticate command. To balance performance and confidentiality of the transaction, each data block in a sector can be configured to allow or disallow sending/receiving plain data. |
|
ссылки URL |
| Вашему бизинису помогли Аллдатащит? [ DONATE ] |
Что такое Аллдатащит | реклама | контакт | Конфиденциальность | Ссылка на техническое описание | обмен ссыками | поиск по производителю All Rights Reserved©Alldatasheet.com |
| Russian : Alldatasheetru.com | Korean : Alldatasheet.co.kr | Spanish : Alldatasheet.es | French : Alldatasheet.fr | Italian : Alldatasheetit.com Portuguese : Alldatasheetpt.com | Polish : Alldatasheet.pl | Vietnamese : Alldatasheet.vn Indian : Alldatasheet.in | Mexican : Alldatasheet.com.mx | British : Alldatasheet.co.uk | New Zealand : Alldatasheet.co.nz |
|
Family Site : ic2ic.com |
icmetro.com |