Bijective MAC for Constraint Nodes
draft-urien-core-bmac-12
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Pascal Urien | ||
| Last updated | 2023-12-29 (Latest revision 2023-06-21) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
In this draft context, things are powered by micro controllers units (MCU) comprising a set of memories such as static RAM (SRAM), FLASH and EEPROM. The total memory size, ranges from 10KB to a few megabytes. In this context code and data integrity are major security issues, for the deployment of Internet of Things infrastructure. The goal of the bijective MAC (bMAC) is to compute an integrity value, which cannot be guessed by malicious software. In classical keyed MACs, MAC is computing according to a fixed order. In the bijective MAC, the content of N addresses is hashed according to a permutation P (i.e. bijective application). The bijective MAC key is the permutation P. The number of permutations for N addresses is N!. So the computation of the bMAC requires the knowledge of the whole space memory; this is trivial for genuine software, but could very difficult for corrupted software, especially for time stamped bMAC.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)