APPLICATION NOTE - Winbond · APPLICATION NOTE Winbond Confidential How to Use W74M Secure Authentication Flash AN0000015 [7] March 14, 2017 Revision 1.1 2. Use Scenario of Electric

APPLICATION NOTE

Winbond Confidential How to Use W74M Secure Authentication Flash

AN0000015 [1] March 14, 2017 Revision 1.1

Table of Content

1. Preface and Security Needs ............................................................................................................................................................... 2 2. Use Scenario of Electric Control Sub-System ................................................................................................................................... 7

2.1 Industry Edge Device Authentication ............................................................................................................................... 8 2.2 Automotive Module Authentication ................................................................................................................................. 9

3. Authentication Theory ..................................................................................................................................................................... 11 4. Host and W74M System .................................................................................................................................................................. 16 5. How to Use W74M Secure Authentication Flash ............................................................................................................................ 20

5.1 Write Root Key (H’9B + H’00) ...................................................................................................................................... 21 5.2 Update HMAC Key (H’9B + H’01) ............................................................................................................................... 23 5.3 Increment Monotonic Counter (H’9B + H’02) ............................................................................................................... 24 5.4 Request Monotonic Counter (H’9B + H’03) .................................................................................................................. 26 5.5 Status Read (H’96) ......................................................................................................................................................... 28

6. Demonstration Example .................................................................................................................................................................. 30 6.1 Write Root Key (H’9B + H’00) ...................................................................................................................................... 32 6.2 Update HMAC Key (H’9B + H’01) ............................................................................................................................... 34 6.3 Increment Monotonic Counter (H’9B + H’02) ............................................................................................................... 36 6.4 Request Monotonic Counter (H’9B + H’03) .................................................................................................................. 38

7. Software Implementation (Reference) ............................................................................................................................................. 43 7.1 Host Application ............................................................................................................................................................. 43 7.1.1 Write Root Key (Initial Operation) .................................................................................................................................... 47 7.1.2 Update HMAC Key ........................................................................................................................................................... 49 7.1.3 Increment Monotonic Counter .......................................................................................................................................... 49 7.1.4 Request Monotonic Counter (Authentication command) .................................................................................................. 50 7.1.5 Status Read (Check command execution result and authentication result) ....................................................................... 51 7.2 Edge Module Application ............................................................................................................................................... 52 7.2.1 Data Input Process from Server to Microcontroller .......................................................................................................... 52 7.2.2 Security Commands Management ..................................................................................................................................... 53 7.2.4 Data Format and Packetizing ............................................................................................................................................ 58 7.2.5 Data Packetizing by High-Performance Microprocessor (FOR REFERENCE) ............................................................... 60 7.2.6 Microcontroller code Structure and Size (FOR REFERENCE) ........................................................................................ 61

8. Appendix ......................................................................................................................................................................................... 62 8.1 Application Development Tools ..................................................................................................................................... 62

APPLICATION NOTE



1. Preface and Security Needs Since semiconductor Integrated Circuits (IC) chips revolution in 1960’s, evolution of semiconductor chips have breathed

new creation into many applications, and the semiconductor chips contributed to legacy mechanical/electronical system drastically in terms of down-sizing, low power dissipation, intelligence, flexibility, usability, safety etc. Microprocessor and microcontroller has rapidly grown, and those are well adopted from super-computer to white-goods and toys. Represented by Internet, computer network system has also well developed and Information Communication Technology (ICT) has flourished. In 2014, concept called “Internet of Thigs (IoT)” was frequently broadcasted by evangelist, and now many working group and media advocate that “More Connect” can add new values and be trigger to open new business model in various segments; office, factory, residential, automotive and anywhere as far as people is living. There new services connected to cellular/Smartphone, wired/wireless internet and cloud server has flourished. Contrary to such convenient system and environment, cyber-attack of rubbery of credential data, system functionality corruption and other threats have come up with. For enterprise server and computer system, firewall and anti-virus check/quarantine software have well developed from its background culture, however it is continuously updated daily basis against new technique and malicious software revolution. Similar problem is happening to embedded world such as consumer network devices, mobile/wearable devices, healthcare instruments, industry, plant, automotive, avionics and so on. Without security workaround (ex. End to End authentication), significant but unexpected system damage may occur under more and complex connectivity environment. In another aspect, “Open Standard” has also been developed to establish “Eco System”. This activity must provide standardization and compatibility in target system/market; it helps that end-user can have wide selection to purchase from the market. The other hand, hacker can easily obtain the specification how to access the devices through well-known interface; it will be more chances to sniff/steal/corrupt the systems. This is major reason why security needs is recently and highly raised in the field of not only Enterprise system but also Smartphone, consumer electronics, Industry, Automotive and whatever any embedded applications which is connected to Internet (IoT applications) in these days.

Figure 1 shows three Security Categories. The first category is “Confidentiality”, that is security engineering to hide and protect data in case that the data can be disclosed to public place. The second once is “Authentication” which is security engineering to evince “What the entity1 only has.” Uniqueness is one of authenticator, and digital Signature based on Asymmetric Key (Public Key and Private Key) is one of authentication methodology. The third one is “Integrity” which evinces “The data is original and never manipulated.” Which security category should be used will depend on system needs. Normally security applications will use combination of the three security categories.

1 Entity is an object to authenticate or to be authenticated. That can be Sender and Receiver, Host and Edge which may be human being, mechanical systems, electrical devices or software systems etc., and those combinations.

APPLICATION NOTE



Figure 1. Security Categories (Three Triangle)

In this document, one of security categories; “Authentication” is picked up and Winbond’s Secure Authentication Flash products named W74M are introduced. In the authentication scheme, algorithm related to “Integrity” is also combined. For “Confidentiality”, algorithm like DES/AES (Symmetric Key basis) and RSA/ECC (Asymmetric Key basis) are used, and the confidentiality purpose is out of scope of the document.

What security can be supported by the W74M is illustrated in two scenarios; one is Authentication to identify proper device/module (Figure 2a), and the other is Anti-Cloning to help fake products to protect original manufacturer (Figure 2b).

Figure 2a. W74M Use Case – Authentication

APPLICATION NOTE



Authentication scenario is shown in Figure 2a, as recent network system consists of host module and edge (slave) modules. In this example, one edge module is equipped with a microcontroller and a W74M secure authentication flash memory. Even if the microcontroller doesn’t have authentication capability (ex. Legacy microcontroller), neither bus interface does (ex. Legacy bus interface), adding W74M to each edge module board can enable authentication network system as total system. When “Strayed”, “Improper” or “Hacking” module were attached on the network, host can figure out which module may be the one. That is, before system operator starts service application of the system, operator can try authentication and diagnose whole devices on the network.

When hacking module pretends edge module, host module can verify the properness by sending “Challenge” message to each edge module. When hacking module pretends host module, W74M will return error status to microcontroller (bridge logic to host module) of the edge module board, so that the microcontroller can take necessary action to report error. This document assumes that host module is always proper and not hacked.

Anti-Cloning scenario is shown in Figure 2b. In this scenario, W74M is used for boot flash memory for microprocessor. Generally, the external flash memory can be readable on PROM Reader/Writer. After memory dump execution, the same code can be programmed to other new flash memory, even the same part number as W74M. That implies “Fake products can be mass-produced by other makers without paying efforts to develop the software.

Figure 2b. W74M Use Case – Anti-Cloning

APPLICATION NOTE



The W74M secure authentication flash can prevent from such illegal production copy to some extent.

Driver software to manage the W74M can be reserved in top block of flash memory, or reserved in MASK ROM of some microprocessors as part of boot code. The software only knows Key information (linked to uniqueness) which is shared with specific W74M assembled at factory, so authentication process (“Challenge and Response”; described in details in chapter 3) will succeed. However if the W74M is improper or other flash memory is for booting, the authentication process will fail because key and monotonic counter value (later explained) are different from expectation or authentication command shall just fail, so that host software can terminate more operation to go.

NOTE:

For production, key (Root Key; explained in Chapter 3) must be installed in factory. During system designing, security system has to be carefully architected as total system. With only W74M secure authentication memory, security system cannot be performed. In Figure 2c, security system design guideline example is illustrated.

APPLICATION NOTE



Figure 2c. Security System Design Guideline with W74M

APPLICATION NOTE



2. Use Scenario of Electric Control Sub-System General Electric Control Sub-System is illustrated in Figure 3a. Left block is Host Module with microprocessor where

SPI flash memory is used as system boot device and data storage. After Power-On-Reset, the microprocessor start to fetch boot code out of the external SPI flash memory. There CPU can configure stack pointer, memory/interface initialization and fetch/load next code from the SPI flash memory, and expand larger scale program to on-chip memory or DRAM to handle step by step.

Right block in Figure 3a is Edge (slave) Module which is connected to Host Module over Bus Interface. In this example, EEPROM/Flash memory is attached to microcontroller for more data storage.

In this way, total electric control system is constructed with multiple sub-systems and each module has each function under connectivity network. Number of Host Module and Edge Module can be one or hundreds in certain system. In near future, when the network system was complicated in conjunction with Internet (everyone in World-Wide can connect), where threat comes from, where malware is injected from, and what influence come up with the system, have to be considered to secure the system, so that “End to End” security must be important needs for near future.

Figure 3a. General Electric Control Sub-System Example

W74M Secure Authentication Flash memory can provide “Authentication” feature and keeps compatibility of generic SPI flash functionality with the same footprint package. If generic flash memory is already used on the PCB, “Replace and Drop” with the W74M can start “Authentication” system easily without changing any hardware system, so that “End to End” security based on “Authentication” can be developed and implemented. Below is some cases of potential applications.

APPLICATION NOTE



2.1 Industry Edge Device Authentication Industry system is made of PLC/Computer System, edge modules and a lot of sensor devices which constructs network

over industry standard bus (Modbus, Profibus, CC-Link, and EtherCAT etc.). Acquired data will be uploaded to cloud server to be shared or analyzed for valuable service or system diagnostic to keep system stability and foresee system failure in advance. The industry system is sometime constructed under “Huge Connectivity”, and “Authentication” on Gateway to modules, and module to module can be important, otherwise hacking devices/malware could be injected in the system and make the system compromised. Also properties (ex. Know-How data) has to be protected from leakage.

When host system sends command/data to edge module, and when edge module was requested query from host system, both parties must mutually recognize if other party is really proper to communicate or reliable. With only unique identifier (ID), it can be easily hacked and spoofed even though the data is encrypted. So cipher algorithm to authenticate and check integrity in better way should be applied. Figure 3b shows 2 step authentication of Industry System; one is authentication between Cloud server and Host System (ex. When first system activation) and the other is module authentication between hosts system and edge module before allowing normal operation.

Figure 3b. Application Example in Industry System (2 step authentication)

1) Cloud server will verify if Host System is proper before activation whole system (1st authentication step). 2) After Cloud server successfully authenticated Host System, then the Host System will verify each Edge Module to be proper (2nd

authentication step). 3) Host System can initiate authentication mode periodically to check if improper module is connected on the bus, so that it can

maintain system health.

APPLICATION NOTE



In this scenario, Cloud server has to manage Root Key for the Host System, and the Host System has to manage Root Keys for Edge Modules A and B. For Edge Module side, the Root Key is securely stored in secure storage of W74M secure authentication flash memory so microcontroller of Edge Module may not have secure storage.

NOTE:

In order to perform complete security system, both Secure Storage and Trusted Execution Environment must be well implemented. System designer must consider “What target application is.”, “What security needs are and what threats should be considerable.”, “Allowable development and implementation cost” and “Impact to incumbent products when applied new system”.

2.2 Automotive Module Authentication It is said that over 70 ECUs (Electrical Control Unit) are used in modern car. The car system also has network system

inside and separated into two domains; control domain represented by engine/body control, and infotainment represented by navigation system/DVD player. In these days, richer navigation, remote services on Bring Your own Device (BYOD), intelligent ADAS with sensor fusion, smart cockpit system and autonomous driving powered by ICT technology over Internet connection is in boom.

The other hand, legacy interface such as system maintenance port (a.k.a. ODB-2 port) and CAN bus network is constructed from Gateway to each MCU module. As easily imagined, the network system is becoming so complicated and there can be security whole where Hacker attacks and make the car under their control in terms of “Direct manipulation to the target” or “Indirect manipulation to the target over wireless interface”.

In order to protect or mitigate such legacy and cyber-attack, Automotive OEMs and Suppliers have started security workaround in car system from high layer (ex. Cloud server to TCU), middle layer (ex. Gateway) and to low layer (ECU and sensor module) to realize safer autonomous driving system for near future.

The W74M secure authentication flash can be utilized in low layer as list below (example).

a) ECU to ECU authentication on legacy ECUs over CAN/Lin bus b) Gateway to ECU authentication for secure Firmware updates Over the Air (FOTA) c) Secure bridge between wireless interface and legacy wired interface. d) Anti-cloning of microprocessor code

As written here, majority of systems are operating not alone but constructing in multiple devices under master and slave communication. One of security categories shown in Figure 1, “Authentication” means to verify “Now I’m talking to whom.” When case b) is picked up as an example, one ECU request Firmware updates Over-The-Air. There three

APPLICATION NOTE



authentication must be necessary at least; one is between Cloud Server and TCU, second is between TCU and Gateway, and third is between the Gateway and the ECU (Figure 3c). TCU may have UICC (Universal Integrated Circuit Card; authentication chip defined by GSMA), but on local bus and Gateway/ECU, there was no security system in the past.

In the third case, there are many ECUs, and Gateway has to distinguish which destination should be target for the FOTA. Just unique address can be easily spoofed by “Man-In-The-Middle Attack” theoretically. Attacker may try “Replay” attack and replace with malicious code from original code.

Figure 3c. Application Example in Car Network System

W74M provides Hash based Message Authentication Code (HMAC) logic in it, so Gateway can try “Challenge and Response” to authenticate the ECU, before starting FOTA. There a microcontroller of the ECU will act as “Software Bridge” for coming commands from Gateway to W74M and passing responses from W74M to Gateway. The Gateway can verify target ECU integrity and the ECU can verify if source entity is really proper Gateway under cipher standard algorithm (mutual authentication) even under public environment where Hacker tries to compromise. As explained later in this document, the authenticator is liked with Root Key and Monotonic Counter which each entity shares in secure manner.

APPLICATION NOTE



3. Authentication Theory In previous section, why authentication and integrity scheme is significant is described for coming “More

Connectivity” applications. For the solution, the simplest implementation can be utilizing unique identifier (for example, device/module unique fixed number or MAC address of Ethernet) to distinguish specific device/module, but the communication may be listened by others, and vulnerable against Spoofing and “Man-In-The-Middle” attack. For workaround, there are proprietary method. However endurable algorithm has been well developed by

cryptographers in decades. In security world, “Security by Obscurity” is taboo and standard algorithm must be used and safer way. For authentication, “One Way Function (A function is a kind of compressed algorithm from source data, but it is

hard to reproduce the original source data inversely)” is a core security technology and named “Hash Function”. With the Hash Function, message (input data) and shared key (between parties or entities), Hash based Message Authentication Code (HMAC) is well applied in any security system for authentication. The W74M embeds the HMAC H/W logic in SPI flash memory. In this section, the theory is explained step by step.

Figure 4. Hash based Message Authentication Code (HMAC)

APPLICATION NOTE



The HMAC is well-known methodology to detect malicious manipulation of the data (In other, there is CMAC; Cipher based MAC which is utilizing Block Cipher algorithm). As shown in Figure 4, sender (left side hand) will transmit not only message itself but also digest which was generated from Key and Message through hash function. Receiver (right hand side) will calculate the digest from Message received and internal secret (shared key with sender), and then compare that with digest received from sender. If the comparison was matched, the authentication means successful. This is secured as far as Collision Resistance is strong enough. In this scheme, there is still vulnerability of “Replay” attack. The Replay attack will steal transaction data between

sender and receiver, modify the data (or reuse as is) and try “Spoofing” as if the hacking entity acts as proper sender/receiver. Hacker may attack by utilizing past transaction which had ever used by sender/receiver, and tries to damage both proper entities. In order to make Hacker harden to attack, standard, matured and stronger in Collision Resistance hash function should be used (ex. SHA-2 rather than SHA-1). For next, new factor will be added for safer security against Replay attack as shown in Figure 5.

Figure 5. Injection of Dynamic Factor into MAC

Difference from Figure 4 is that “Dynamic Data” was added for hash function arguments. Even though Hacker listened to the transaction, the sender/receiver can change the dynamic data frequently by certain scheme, which can harden for hacker to perform Replay attack by man-in-the-middle. When Hacker sensed one transaction (Message and Digest) at one timing, but the Digest cannot work for even with

the same Message in the next timing, because new Digest must be created of new Dynamic data which shall be totally different number from last.

APPLICATION NOTE



At last, “Key” has to be the most precious to be protected, and normally the key had better to keep its original and create other operation key for application use. So that in case that one operation key was leakage by incident, new operation key can be created for next use. Moreover frequent changes of the operation key will be effective from view of security maintenance. Figure 6 illustrates the scheme.

Figure 6. Operation Key (Session Key) Creation for Application Use The operation key (Session Key; W74M has the name denoted as “HMAC Key” later.) can be created from original key (W74M has the name denoted as “Root Key”) and seed which can be random number or any other data (ex. Unique ID, date code etc.). Please note that the original key (Root Key) has to be always protected by both entities and only the Seed may be sent it out “as is” to other entity. Inherently the seed data is random number against hacker so taking out from sender entity has to be considered as secure. Total HMAC system is illustrated in Figure 7a.

APPLICATION NOTE



Figure 7a. Total HMAC System

The total HMAC system can authenticate entity by verifying “Integrity” of the message and work for anti-Replay attack. In other words, as long as the same Root Key is secured/shared by each entity, sender entity can authenticate “Who you are” to other entity. Here is summary for the authentication process.

1) Set shared Root Key at factory in both Sender and Receiver in advance. 2) Sender will create Random Number periodically and send that to Receiver, and update Session Key

(HMAC Key). For authentication, the Session Key (HMAC Key) will be used. 3) For anti-Replay Attack, both Sender and Receiver will share and synchronize the same dynamic Data

which will be one input argument to calculate Digest, which will be sent to Receiver with Message. To speak strictly, here is still vulnerability potential here; how to keep Root Key securely and how to ensure trusted

S/W execution. This must be designed by system architect, software developer and semiconductor chip developer, which is chance to show off. How much security efforts can be paid shall come from actual business criteria such as security target, security needs level, threats and considerable impact, allowable cost, feasibility study of incumbent applications, business model and marketing strategy etc. W74M Secure Authentication Flash memory integrates HMAC-SHA256 crypto engine, secure storage to reserve Root Key/HMAC Key and Monotonic Counter. If Device/Module which is to be authenticated doesn’t have any secure storage and HMAC logic (Legacy Microcontroller/Microprocessor), attaching the W74M can provide Authentication System in Slave side (Figure 7b).

APPLICATION NOTE



Figure 7b. Authentication Feature Adding to Legacy Microcontroller/Microprocessor

From next section, Winbond W74M Secure Authentication Flash memory is introduced and how to use it is to be focused on.

APPLICATION NOTE



4. Host and W74M System W74M Secure Authentication Flash memory is serial flash memory developed by Winbond and equipped with

authentication function; HMAC-SHA256 algorithm logic, secure key storage for Root Key and HMAC Key (Session Key), and Monotonic Counter (dynamic data written in previous section). As authenticator resources, the Root Key, HMAC Key and Monotonic Counter are set and constructed as “Token”. The W74M has totally four channels of “Token”, and each “Token” can be selected by “Counter Address (0x00, 0x01, 0x02 and 0c03)”.

In this application note, “Module Authentication” constructed with Host Module and Edge Module as shown in Figure 8 (referenced from Figure 2a) will be treated2. Here the Edge module consists of microcontroller and W74M mutually connected over SPI interface on the same PCB. The W74M can be boot memory, or memory for extra data storage. The microcontroller has its application functions and also acts as “Software Bridge” for command/data between Host module and W74M.

Host module will try to authenticate each Edge module if that is real thing and proper module in terms of “Challenge and Response” over legacy interface.

Figure 8. Module Authentication

2 Please note this is Module Authentication scenario as show in Figure 2a and Figure 8. There is another scenario that

Host (Microcontroller/Microprocessor) wants to authenticate W74M device itself as shown in Figure 2b, where the W74M can work around for “Anti-Cloning (illegal reuse of whole copy of code from original flash memory)”. This document doesn’t explain for the scenario, however “Authentication” scheme is completely same as “Module Authentication” but application implementation is just only different.

APPLICATION NOTE



The overall host state machine flow to control W74M is illustrated in Figure 9, and each state is listed in Table1. In this document, a word of “W74M” is used to represent either “Microcontroller/Microprocessor and W74M module” or just only “W74M memory device”.

Figure 9. Host Authentication State Machine Flow to W74M

APPLICATION NOTE



Table 1. Host Authentication State Machine (Example)

Process Description 1 Idle Host waiting mode for commands. This is default

state. 2 Root Key Storage Before “Write Root Key” command, host shall

retrieve Root Key from storage. This process shall happen at only factory to load Root Key into W74M.

3 “Write Root Key” command Command to load Root Key for W74M. The host may be server or microcomputer. The Root Key is shared secret key between host and W74M, so host has to reserve the key securely.

4 Random Number Generation For security reason, operation key (HMAC key) must be dynamically changed. Host shall generate random number followed by “Update HMAC Key” command.

5 “Update HMAC Key” command Command to update HMAC key by sending the random number to W74M. Root key and HMAC Key are concealed and be never output to the SPI bus.

6 Set TAG (Message) Pre-processing by host to set TAG (message) as payload of “Challenge”.

7 “Request Monotonic Counter” command

Main command of authentication. In addition, the command is used for to request current Monotonic Counter (MC) value of the W74M. “Response” will come out by following “Status Read” command.

8 “Increment Monotonic Counter” command

Command to increment MC value by host to compromise Reply-Attack.

9 “Status Read” command Command to check if previous command was successfully done, or authentication result with MC value comes from the W74M. After any command, host shall initiate “Status Reda” command.

Authentication will be executed by “Request Monotonic Counter” command (“Challenge”). By followed command of “Status Read”, W74M will return answer to Host (“Response”).

In these processes, both Host and W74M calculate and verify as below.

Step-1 (by Host):

Calculate digest from payload and HMAC Key and send those to W74M (“Challenge”).

Step-2 (by W74M):

APPLICATION NOTE



Calculate digest from payload with own HMAC Key, and compare the digest with digest received from Host

(“Authenticate Host”).

Step-3 (by W74M):

Calculate digest with payload, HMAC Key and Monotonic Counter value, and send those to Host (“Response”).

Step-4:

Calculate digest from payload with own HMAC Key and Monotonic Counter, and compare the digest with digest received from W74M (“Authenticate Edge”).

Here Host and W74M mutually authenticate and twice HMAC calculation is executed by each entity (Figure 10).

Figure 10. Authentication (“Challenge and Response”)

APPLICATION NOTE



5. How to Use W74M Secure Authentication Flash The W74M is one of Winbond SPI flash memory products to integrate security features into conventional SPI flash

memory. Main features are listed as below.

1) 104MHz Standard/Dual/Quad SPI clocks operations to host microprocessor (208/416MHz equivalent performance at Dual/Quad SPI mode)

2) 50MB/S transfer rate in continuous data mode 3) More than 100,000 erase/program cycles 4) More than 20-year data retention 5) Operational voltage: 2.7 to 3.6V on single power supply 6) Operating temperature range: 40°C to +85°C 7) OTP lockable security registers with 256-Bytes x 3 blocks 8) Four tokens configurable with OTP Root Key, Volatile HMAC Key storage, and Non-volatile Monotonic

Counter (MC) 9) HMAC-SHA256 dedicated H/W logic in SiP

Key feature of the W74M is Hash based Message Authentication Code (HMAC) based on SHA-256 algorithm. As explained in Section 3, the W74M has a dynamic data factor; Monotonic Counter (MC) in Non-Volatile register to compromise against “Spoofing” or “Replay Attack” under “Man-In-The-Middle” which will listen to communication between proper entities.

In order to facilitate the security features, next five commands are equipped into the W74M in comparison with conventional SPI flash memory like W25Q series as follows. The parenthesis indicates instruction sets from host to the W74M.

a) Write Root Key (H’9B + H’00) b) Update HMAC Key (H’9B + H’01) c) Increment Monotonic Counter (H’9B + H’02) d) Request Monotonic Counter (H’9B + H’ H’03) e) Status Read (H’96)

From next section, each command is to be explained.

APPLICATION NOTE



5.1 Write Root Key (H’9B + H’00) This command is only issued to inject shared Root Key into the W74M of sub-system board at factory installation stage.

Normally the Root Key has to be program in terms of “On-Board” or “In-System” manner. Once the command was executed, the Root Key cannot be reset, modified and taken out from the chip, and stored into secure storage.

In Figure 11, the Write Root Key command protocol is depicted, and each command phase is listed in Table 2.

Figure 11. Write Root Key Command

Table 2. Write Root Key Command

Order 1 2 3 4 5 6 Attribute

[bit length] Instruction

[8] Command

type [8]

Counter Address

[8]

Reserved [8]

Root Key [256]

Digest [224]

Data[Hex] 9B 00 00 to 03 00 ANY (256’

0xFF..FF can be

used for test.)

Digest = HMAC_SHA256 (Message, Key)

Description Write Root Key command Indicate token number 00 to 03

- Root Key Least significant 224 bits of HMAC-SHA256 which input is as follows. Message= payload from instruction to reserved data (0x00), Key: Root Key

After the Write Root Key command was issued, host shall try Status Read command as shown in Figure 12.

APPLICATION NOTE



igure 12. Status Read Command

Host shall check the first byte of MC status (other data is ignorable in the command.) as follows.

Table 3. Status Register after Write Root Key Command

Status Bits Description 1 0b 1000_0000 Command successful completion 2 0b 0xxx_xxx1 In command process and busy 3 0b 0xxx_xx1x Root Key overwrite error, out of range in counter address error or

digest mismatch error

The returned value in tag, Counter Data and Signature are invalid and ignorable on Status Read command after Write Root Key command.

APPLICATION NOTE



5.2 Update HMAC Key (H’9B + H’01) This is a command to update HMAC Key which is corresponding to Operation (Session) Key which was explained in

Section 3 and Figure 6. For seed, Host can utilize any unique data sources; number from Random Number Generator (RNG), Unique ID, Manufacturing ID, tracking number, password and etc. Frequent issuing the command; at every Power-On-Reset or every seconds/minutes is preferable to make hacker compromise.

In Figure 13, the Update HMAC Key command protocol is depicted, and each command phase is listed in Table 4.

Figure 13. Update HMAC Key Command

Table 4. Update HMAC Key Command



[8] Command

type[8] Counter

Address[8] Reserved[8] Key

Data[32] Signature[256]

Data[Hex] 9B 01 00 to 03 00 ANY HMAC(HMAC key, payload)

Description Update HMAC Key command

Indicate token number 00 to 03

- Seed to renewal HMAC key

HMAC-SHA256 which inputs are as follows. Message= payload from instruction to seed, Key: current HMAC key

After the Update HMAC Key command was issued, host shall try Status Read command as shown in Figure 14.

APPLICATION NOTE



Figure 14. Status Read Command after Update HMAC command

Host shall check the first byte of MC status as follows.

Table 5. Status Register after Update HMAC Key Command (MC status)

Status Bits Description 1 0b 1000_0000 Command successful completion 2 0b 0xxx_xxx1 In command process and busy 3 0b 0xxx_xx1x Out of range in counter address error 4 0b 0xxx_x1xx Digest mismatch, out of range in counter address error, out of

range in command or incorrect payload size.

The returned value in tag, Counter Data and Signature are invalid and ignorable on Status Read command after Update HMAC Key command.

5.3 Increment Monotonic Counter (H’9B + H’02) This is a command to increment Monotonic Counter (MC) of W74M which is corresponding to Dynamic Data which

was explained in Section 3 and Figure 5. If Host doesn’t know the latest counter value, Host cannot execute this command properly. Host can know the latest counter value when authentication was successfully done (Request Monotonic Counter command). Hacker may listen to communication data between parties, and reuse the data for spoofing attack. The MC can be incremented randomly and frequently between Host and W74M, so that message contains MC value at one moment can be garbage for Hacker.

In Figure 15, Increment Monotonic Counter command protocol is depicted, and each command phase is listed in Table 6.

APPLICATION NOTE



Figure 15. Increment Monotonic Counter Command

Table 6. Increment Monotonic Counter Command



[8] Command

type[8] Counter

Address[8] Reserved[8] Counter

Data[32] Signature[256]

Data[Hex] 9B 02 00 to 03 00 ANY Digest = HMAC_SHA256 (Message, Key)

Description Increment Monotonic Counter command


- Current MC value

HMAC-SHA256 inputs is as follows. Message= payload from instruction to counter data, Key: HMAC Key

After the Increment Monotonic Counter command was issued, host shall try Status Read command as shown in Figure 16.

APPLICATION NOTE



Figure 16. Status Read Command after Increment MC Command


Table 7. Status Register after Increment MC Command (MC status)

Status Bits Description 1 0b 1000_0000 Command successful completion 2 0b 0xxx_xxx1 In command process and busy 3 0b 0xxx_x1xx Digest mismatch, out of range in counter address error, out of

range in command or incorrect payload size. 4 0b 0xxx_1xxx HMAC Key register (or Root Key register) uninitialized on

previous command 5 0b 0xx1_xxxx Counter Data mismatch

The returned value in tag, Counter Data and Signature are invalid and ignorable on Status Read command after Increment Monotonic Counter command.

5.4 Request Monotonic Counter (H’9B + H’03) This is a command to execute authentication and request the latest Monotonic Counter (MC) value of W74M.

In Figure 17, Request Monotonic Counter command protocol is depicted, and each command phase is listed in Table 8.

APPLICATION NOTE



Figure 17. Request Monotonic Counter Command

Table 8. Request Monotonic Counter Command



[8] Command

type[8] Counter

Address[8] Reserved[8] Tag

[96] Signature[256]

Data[Hex] 9B 03 00 to 03 00 ANY Digest = HMAC_SHA256 (Message, Key)



- 12 byte payload to be added

HMAC-SHA256 inputs is as follows. Message= payload from instruction to Tag, Key: HMAC Key

After the Request Monotonic Counter command was issued, host shall try Status Read command as shown in Figure 18.

APPLICATION NOTE



Figure 18. Status Read Command after Request MC Command


Table 9. Status Register after Request MC Command (MC status)

Status Bits Description 1 0b 1000_0000 Command successful completion 2 0b 0xxx_xxx1 In command process and busy 3 0b 0xxx_x1xx Digest mismatch, out of range in counter address error, out of

range in command or incorrect payload size. 4 0b 0xxx_1xxx HMAC Key register (or Root Key register) uninitialized on

previous command

The returned value in tag, Counter Data and Signature are valid on Status Read command after Request Monotonic

Counter command when authentication was successful (MC status byte = 0x80). When authentication was failed (MC status byte != 0x80), those payload is to be invalid and ignorable.

5.5 Status Read (H’96) The Status Read Command is also called “Read Authentication Flash Device Status/Data”, and is mandatory command

when other four commands were executed to confirm if the command was processed properly.

In Figure 19, Status Read command protocol is depicted, and each command phase is listed in Table 10.

Figure 19. Status Read Command

Table 10. Status Read Command



[8] Dummy

[8] MC status

[8] Tag [96]

Counter Data [32]

Signature[256]

APPLICATION NOTE



Data[Hex] 96 00 xx Tag xxxx Digest = HMAC_SHA256 (Message, Key)


Dummy Status The latest MC number

HMAC-SHA256 inputs is as follows. Message= payload from instruction to Counter Data, Key: HMAC Key

Note: Hatching portion is data out of W74M.

For MC status for each command, please see Table 3, 5, 7 and 9.

Again, when previous command was Request Monotonic Counter, MC status byte means as Table 11 and 9.

Table 11. Status Register in Request MC Command (MC status)

Status Bits Description 1 0b 1000_0000 Command successful completion 2 0b 0xxx_xxx1 In command process and busy 3 0b 0xxx_xx1x Out of range in counter address error 4 0b 0xxx_x1xx Digest mismatch, out of range in counter address error, out of

range in command or incorrect payload size.

When the MC Status bits was b’80 (both command and authentication successful), all returned value in tag, Counter Data

and Signature are valid in Status Read Command. Host shall calculate its own digest and compare digest (signature) received from W74M.

Please refer to W74M Datasheet for overall H/W specification.

W74M Datasheet:

3V xM-BIT

SERIAL FLASH MEMORY WITH

DUAL/QUAD SPI & SECURE AUTHENTICATION

APPLICATION NOTE



6. Demonstration Example As demonstration example, Server to Edge Module authentication over Bluetooth is introduced. The Edge Module

system and the overall system diagram are illustrated in Figure 20 and 21. The Edge Module is consists of Renesas R8C/29 microcontroller, W74 and Bluetooth module. The W74M is extra memory storage and connected to the microcontroller via SPI interface.

In this demonstration scenario, Server will work an Authenticator, and send “Challenge” to W74M via microcontroller and verify “Response” from W74M via microcontroller, so that Server can authenticate if the Edge Module is genuine module and proper.

Figure 20. Edge Module with W74M

Figure 21. System Diagram

APPLICATION NOTE



Basic Operations:

1) Server will send “Challenge” commands to a microcontroller over Bluetooth interface (Java application serves UI to configure data and status.).

2) When microcontroller received the commands, microcontroller will packetize those data to fit to W74M and send the data to W74M.

3) When W74M received the data, W74M will calculate cryptographic process and send “Response” back to the microcontroller.

4) The microcontroller will packetize the received data and send back the response to Host. 5) The Host will verify the response (MC status byte and digest in comparison with its own calculated digest). If the MC

status byte equals to 0x80 and digest was match, the Server could authenticate the Edge Module successfully.

From next sections, each security command implemented in W74M is demonstrated.

APPLICATION NOTE



6.1 Write Root Key (H’9B + H’00) On the demonstration application, Write Root Key Command looks like Figure 22 as below.

1) Counter Address: H’03 2) Root Key: all H’FF in 32 bytes (256 bits) 3) Digest (Signature): as show in below. Only least significant 224 bits

Figure 22. Write Root Key Command

APPLICATION NOTE



The digest (Signature) it to be calculated as follows.

Digest = hmac_sha256 (Key, Message)

Where:

Key = Root Key = H’FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Message = Instruction + Command + Counter Address + H’00

= H’9B000300

Status Read Command is illustrated in Figure 23. The MC Status is H’80 (top 1 byte data of response) so the command was executed successfully.

APPLICATION NOTE



Note: The Java Application automatically calculate and compare all payload (Tag, Counter Data and Signature) later than MC status byte (top 1 byte). Status Read command after commands besides Request MC Command has INVALID payload so the digest comparison is failed (authentication failed), which is normal.

Figure 23. Status Read followed by Write Root Key Command

6.2 Update HMAC Key (H’9B + H’01) Update HMAC Key Command looks like Figure 24 as below.

1) Counter Address: H’03 2) Random number: H’bb0fe0fa (32 bits) 3) Digest (Signature): 256 bits length as show in below.

APPLICATION NOTE



Figure 24. Update HMAC Key Command



Where:

Key = HMAC Key (=H’11D50CC4E76E15A2CC482CD97675B58562A17184764965776D0A848BDFC7A790)

Message = Instruction + Command + Counter Address + H’00 +

Random Number = H’9B010300 bb0fe0fa

APPLICATION NOTE





Figure 25. Status Read followed by Update HMAC Key Command

6.3 Increment Monotonic Counter (H’9B + H’02) Increment Monotonic Counter (MC) Command looks like Figure 26 as below.

1) Counter Address: H’03 2) Counter Number: H’00000000 (32 bits) � The number must be current counter number. Host must know that. 3) Digest (Signature): 256 bits length as show in below.

APPLICATION NOTE



Figure 26. Increment MC Command



Where:


Message = Instruction + Command + Counter Address + H’00 +

APPLICATION NOTE



Counter Data = H’9B02030000000000



Figure 27. Status Read followed by Increment MC Command

6.4 Request Monotonic Counter (H’9B + H’03) Request Monotonic Counter (MC) Command is main body to achieve authentication, and looks like Figure 28 as below.

APPLICATION NOTE



1) Counter Address: H’03 2) Tag: H’000102030405060708090a0b (32 bits) � The Tag can be any data/message in the application. 3) Digest (Signature): 256 bits length as show in below.

Figure 28. Request MC Command

APPLICATION NOTE





Where:


Message = Instruction + Command + Counter Address + H’00 + Tag

= H’9B0303000001020304050607080900a0b

Status Read Command is illustrated in Figure 29. The MC Status is H’80 (top 1 byte data of response) so the command was executed successfully. Counter Data is read as H’00000001 of red rectangle in Figure 29.

Payload other than MC Status (Tag, Counter Data and Digest) shall be treated as VALID and the digest is to be calculated as follows.


Where:


Message = Instruction + Tag + Counter Value (32bit)

= H’90000102030405060708090A0B00000001

Host shall calculate by the same condition and compare with the digest received from W74M. In Figure 29, “Result” is digest came from W74M, and “Original” is digest calculated by Host.

APPLICATION NOTE



Figure 29. Status Read followed by Request MC Command (Authentication Successful)

If the authentication failed, the result looks like as Figure 30. This was caused because wrong root key was used by host program.

APPLICATION NOTE



Figure 30. Status Read followed by Request MC Command (Authentication Failed)

Consequently the demo has confirmed as follows.

a) Binding with shared Root Key at first step (only necessary at initialization process) by Write Root Key command b) Check command execution status by Status Read command c) Perform Update HMAC key (operation/session key used in user application) by Update HMAC command d) Check command execution status by Status Read command e) Perform Increment MC command for randomization for hacker f) Check command execution status by Status Read command g) Perform Request MC command (“Challenge”) h) Perform Status Read command to verify authentication (“Response” from W74M) and confirm MC value

Note: After each step, Status Read shall be issued to check if the command was successfully done, or check if the authentication was passed.

APPLICATION NOTE



7. Software Implementation (Reference) As shown in Section 6, demonstration uses Host Application of Server (Java Application) and microcontroller application software to bridge Server to W74M for Edge Module. Here each application software is explained.

7.1 Host Application Host application consists of two windows; one is Main Window (Figure 31) where transaction status is shown, and the

other is Security Window (Figure 32) where each security command is called and payload can be configured in manual. Buttons and text windows of Main Window and Security Window are explained in Table 12 and Table 13.

Figure 31. Host Application (Main Window)

APPLICATION NOTE



Figure 32. Host Application (Security Window)

APPLICATION NOTE



Table 12. Host Application Features (Main Window)

Button/Window Function 1 COM Port select Select Bluetooth/Serial COM port number to

communicate microcontroller 2 Baud Ratio select Select Baud ratio to communicate microcontroller 3 Connect button Open the COM port connection 4 Disconnect button Close the COM port connection 5 Message window Response from microcontroller and management

message out of application (ex. authentication success/failure) will be shown up here.

6 Manual Command window

Set manual command for W74M. The data format is: W74M serial flash command + space + memory/block address + space + arguments (example) 03 000000 1 (memory dump from H’000000 to 1 word) Please see W74M datasheet for standard memory commands.

7 Commit button Initiate the manual command. 8 Security button In this demonstration system, this button must be pushed

when security commands will be used. 9 Normal button Return to normal mode after security command use. 10 Clear Console button Clear Main Window. 11 Other buttons These are out of scope of the application note. Those

buttons are used for flash memory basic functions and test.

APPLICATION NOTE



Table 13. Host Application Features (Security Window)

Button/Window Function 1 Data format select radio

button in Key Window Data format of Key Window (in default: Text mode) is set. Select Binary radio button for the demonstration.

2 Data format select radio in Message Window

Data format of Message Window (default: Text mode) is set. Select Binary radio button for the demonstration.

3 Root Key and Digest button

When this button hit, data of Key Window and data of message Window will be fed and calculate digest on HMAC-SHA256. The result will show up in Key Window. Key length must be 32 bytes.

4 Key Window Key data is set here. 32’s H’FF will be set after the application launch, or hit Clear Console button. In security command process, here digest will show up.

5 Message window Payload, or Tag (Message) for Request Monotonic Counter command is set here. When each security command was executed, corresponding payload will be automatically set here. In case of Request Monotonic Counter command, please set “Tag (Message)” data here by using Message File button.

6 Message File button To select pre-loaded file. Used for set “Tag (Message)” data for Request Monotonic Counter command.

7 Key Status (Root at first and HMAC key at 2nd) window

Here Root Key will be copied at beginning by Write Root Key command, and HMAC key will be memorized by Update HMAC Key command.

8 RNG Input button When Update HMAC Key command is executed, random number shall be fed as payload. This button will create the random number.

9 Clear Console button Clear all window and set 32’s HFF in Key Window. This button can be used when reset current procedure.

10 Monotonic Counter Select (00 to 03) window

Select Monotonic Counter address (“Token” channel).

11 32-bit Monotonic Counter Number window (at last)

32’s 0 is default. Before Increment Monotonic Counter command, here the latest MC value must be set here manually. Otherwise, the Increment Monotonic Counter command will fail (anti-Replay attack).

12 Write Root Key button Execute Write Root Key command. 13 Update HMAC Key

button Execute Update HMAC Key command.

14 Increment Monotonic Counter button

Execute Increment Monotonic Counter.

15 Request Monotonic Counter button

Execute Request Monotonic Counter.

16 Read Status Register button

Execute Status Read command.

APPLICATION NOTE



7.1.1 Write Root Key (Initial Operation) Initial operation flow is illustrated in Figure 33a. Please perform Status Read command to check if the Write Root key

command was successful processed, after the security command was performed. Steps on Server application are illustrated in Figure 33b.

Figure 33a. Initial Operation Flow of Host Application (on Security Window)

APPLICATION NOTE



Figure 33b. Initial Operation Steps of Host Application (Security Window)

After initial operation is completed, Update HMAC Key, Increment Monotonic Counter command and Request Monotonic Counter can be performed. After each security command, please perform Status Read command on Read Status Register button if the previous security command was successful.

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Note:

When each security command is executed, the Host will create data packet by retrieving out of:

1) Payload in Message Window 2) Digest in Key Window

Host application will recognize the data as binary when the “Binary” radio button is active. However when the data will be out over Bluetooth interface from Host, the data format is converted to character code. Therefore when microcontroller received the data, the microcontroller will convert the data to binary internally, and send that to W74M.

Vice versa, response from W74M, the data will be converted in the same manner from microcontroller to Host.

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

APPLICATION NOTE



7.1.2 Update HMAC Key

Update HMAC Key command can be performed by steps as illustrated in Figure 34. After the command execution, please hit Read Status Register button to check if Update HMAC Key command was successful.

Figure 34. Steps for Update HMAC Key command (Security Window)

7.1.3 Increment Monotonic Counter

Increment Monotonic Counter command can be performed by steps as illustrated in Figure 35. This command is helpful to compromise Spoofing and Reply-Attack. After the command execution, please hit Read Status Register button to check if Increment Monotonic Counter command was successful.

APPLICATION NOTE



Figure 35. Steps for Increment Monotonic Counter command (Security Window)

7.1.4 Request Monotonic Counter (Authentication command)

Request Monotonic Counter command can be performed by steps as illustrated in Figure 36. After the command execution, please hit Read Status Register button to check if both Request Monotonic Counter command and authentication were successful.

APPLICATION NOTE



Figure 36. Steps for Request Monotonic Counter command (Security Window)

7.1.5 Status Read (Check command execution result and authentication result)

Status Read command can be performed by step as illustrated in Figure 37.

Figure 37. Steps for Status Read command (Security Window)

APPLICATION NOTE



7.2 Edge Module Application

Edge Module has a W74M secure authentication flash memory which is connected to a microcontroller (Renesas R8C/29) over SPI interface, so that even though the microcontroller doesn’t have security feature, the W74M can provide HMAC-SHA256 processing and secure key storage of the Edge Module.

The W74M is memory device so the microcontroller will act as “Bridge” for data between Server (Host) and W74M. Bluetooth SPP profile is used for interface between Server and microcontroller.

Here microcontroller operation is explained.

7.2.1 Data Input Process from Server to Microcontroller

Data input flow from Server to microcontroller is shown in Figure 38. Besides the task, microcontroller may have main task (for example, actuator control and sensor data acquisition), which is out of scope of this document.

Figure 38. Microcontroller Data Input Process Flow

After initialization, microcontroller waits for command/data from Server. When command/data were received,

microcontroller will convert the data format from Character Code to Binary Code. Then microcontroller checks system mode (either normal mode or security mode) and packetize those data to fit to either standard flash memory command or payload for W74M as illustrated in Figure 39. Please refer to 7.2.4 “Data Format and Packetizing”.

APPLICATION NOTE



Figure 39. Data Packetizing and System Mode Management

7.2.2 Security Commands Management

When system mode is Security Mode, then microcontroller will jump to Security Commands Management function. The W74M secure authentication flash has new five commands as explained in Section 4, 5 and 6 in addition to conventional flash memory commands. The microcontroller will manage those security commands as shown in Figure 40.

Figure 40. Security Commands Management

APPLICATION NOTE



7.2.3 Conventional Flash Memory Commands Management (FOR REFERENCE)

When system mode is not Security Mode that is conventional flash memory commands mode, the microcontroller will manage those commands as shown in Figure 41 to Figure 46.

Figure 41. Conventional Flash Commands Management (1)

APPLICATION NOTE





APPLICATION NOTE





APPLICATION NOTE




APPLICATION NOTE



7.2.4 Data Format and Packetizing

Edge Module (microcontroller and W74M) receives/sends command/data between Server (Host) over Bluetooth/SPP profile. The data format comes from Server (Java application) is character code (for example, ‘1’ is expressed by H’31) so the microcontroller will convert the received data to “Binary” and get rid of space (H’20) and check consecutive CR (H’0D) and LF (H’0C) for delimiter.

Example of Character code to Binary code:

buf[i] = ctoi (rx_buf [i+1]) * 16 + ctoi (rx_buf[i]);

Where rx_buf [] is data reception buffer out of Host.

buf [] is temporary buffer for data transmission for W74M.

ctoi () is a conversion function from character code to Integer.

‘i’ is to be incremented with +2.

‘If space (H’20) comes, the ‘i’ must be incremented with +3

(NOTE: security commands packet doesn’t use space in format of the

Demonstration code but conventional flash memory commands).

As shown in Figure 47, the microprocessor will receive and convert the data into RAM buffer. Green portion is Software process. Please see Section 5 “How to Use W74M Secure Authentication Flash” on each security command format in details.

APPLICATION NOTE



W74m_tx_buf[i] is buffer for SPI interface to communicate to W74M.

Figure 47. Data Packetizing and Software Process (in the demonstration)

APPLICATION NOTE



7.2.5 Data Packetizing by High-Performance Microprocessor (FOR REFERENCE)

In the demonstration of this application note, HMAC-SHA256 for “Challenge” is calculated on Java application of Server, and then the W74M will send “Response” with the integrated HMAC-SHA256 engine, because the scenario is Server is a Host and microcontroller+W74M is an Edge (Slave) to be authenticated.

When Host is high-performance microprocessor (or microcontroller), the Host controller can calculate HMAC_SHA256 on it or integrated HMAC-SHA256 engine. In that case, the data packetizing can be as Figure 48.

W74m_tx_buf[i] is buffer for SPI interface to communicate to W74M.

Figure 48. Data Packetizing and Software Process by High-Performance Microprocessor (only REFERENCE)

APPLICATION NOTE



7.2.6 Microcontroller code Structure and Size (FOR REFERENCE)

In the demonstration, the microcontroller code is structured as in Figure 49.

Figure 49. Microcontroller Code Structure (only REFERENCE)

Code size of each module is listed in Table 14 (only REFERENCE).

Table 14. Code Size of Microcontroller in the Demonstration (only REFERENCE)

Module Size [Byte] 1 Ncrt0.a30 145 2 wb_spi_flash_test.c 5234 3 w74m_spiflash.c 784 4 utility.c 924

Regarding to those sample source code delivery, please contact Sales of Winbond Electronic Corporation.

APPLICATION NOTE



8. Appendix 8.1 Application Development Tools

1) Server Application (Windows 7 32-bit)

Table 15. Development Tools on Server Application Application Tool Description 1 IDE eclipse.platform_4.4.2.v20150204-1700 2 Java jre1.8.0_77 3 Java Libraries files Commons-lang3-3.4

(for HMAC-SHA256) RXTXcomm (for Serial communication)

4 JSmooth 0.9.9-4 a VM wrapper toolkit for Windows

2) Microcontroller Application (Renesas R8C/29)

Table 16. Development Tools on Microcontroller Application

Application Tool Description 1 IDE High-performance Embedded Workshop

Version 4.09.01.007 (Renesas)

2 Compiler C/C++ Compiler Package for M16C Series and R8C Family V.6.00 Release 00 (Renesas)

3 Debugger E8a Emulator Software V.1.05 Release 01 (Renesas)

3) Miscellaneous

Table 17. Miscellaneous Development Tool

Application Tool Description 1 RBT-001 Bluetooth Module configurator Simply Blue Commander

Version 1.6.0.1 (National Semiconductor)

APPLICATION NOTE



Revision History

Version Date Page Description 1.0 07/28/2016 Original

1.1 03/14/2017 Second Release. Description of all sections and diagram were

cleaned up.

Trademarks

Winbond, SpiFlash and SpiStack are trademarks of Winbond Electronics Corporation.

All other marks are the property of their respective owner.

Important Notice Winbond products are not designed, intended, authorized or warranted for use as components in systems or equipment intended for surgical implantation, atomic energy control instruments, airplane or spaceship instruments, transportation instruments, traffic signal instruments, combustion control instruments, or for other applications intended to support or sustain life. Furthermore, Winbond products are not intended for applications wherein failure of Winbond products could result or lead to a situation wherein personal injury, death or severe property or environmental damage could occur. Winbond customers using or selling these products for use in such applications do so at their own risk and agree to fully indemnify Winbond for any damages resulting from such improper use or sales.

Information in this document is provided solely in connection with Winbond products. Winbond reserves the

right to make changes, corrections, modifications or improvements to this document and the products and

services described herein at any time, without notice.

Documents

APPLICATION NOTE - Winbond · APPLICATION NOTE Winbond Confidential How to Use W74M Secure Authentication Flash AN0000015 [7] March 14, 2017 Revision 1.1 2. Use Scenario of Electric