ISO/IEC 20897-1:2020
(Main)Information security, cybersecurity and privacy protection — Physically unclonable functions — Part 1: Security requirements
Information security, cybersecurity and privacy protection — Physically unclonable functions — Part 1: Security requirements
This document specifies the security requirements for physically unclonable functions (PUFs). Specified security requirements concern the output properties, tamper-resistance and unclonability of a single and a batch of PUFs. Since it depends on the application which security requirements a PUF needs to meet, this documents also describes the typical use cases of a PUF. Amongst PUF use cases, random number generation is out of scope in this document.
Sécurité de l'information, cybersécurité et protection de la vie privée — Fonctions non clonables physiquement — Partie 1: Exigences de sécurité
General Information
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 20897-1
First edition
2020-12
Information security, cybersecurity
and privacy protection — Physically
unclonable functions —
Part 1:
Security requirements
Sécurité de l'information, cybersécurité et protection de la vie
privée — Fonctions non clonables physiquement —
Partie 1: Exigences de sécurité
Reference number
ISO/IEC 20897-1:2020(E)
©
ISO/IEC 2020
---------------------- Page: 1 ----------------------
ISO/IEC 20897-1:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 20897-1:2020(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 3
5 Security requirements for PUFs . 3
5.1 General . 3
5.2 PUF interface . 4
5.3 PUF building blocks . 4
5.4 Use cases of PUF . 5
5.4.1 Security parameter generation . 5
5.4.2 Device identification . 6
5.4.3 Device authentication . 6
5.5 Security requirements . 8
5.5.1 General. 8
5.5.2 Steadiness . 9
5.5.3 Randomness. 9
5.5.4 Uniqueness. 9
5.5.5 Tamper-resistance . 9
5.5.6 Mathematical unclonability . 9
5.5.7 Physical unclonability. 9
5.6 Mapping between security requirements and use cases .10
Annex A (informative) Classification of PUF .12
Annex B (informative) Some PUF implementations .13
Annex C (informative) PUF life-cycle .15
Bibliography .16
© ISO/IEC 2020 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 20897-1:2020(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/ patents) or the IEC
list of patent declarations received (see http:// patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www .iso .org/ iso/ foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
A list of all parts in the ISO/IEC 20897 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
iv © ISO/IEC 2020 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 20897-1:2020(E)
Introduction
This document specifies the security requirements for physically unclonable functions (PUFs) for
generating non-stored cryptographic parameters.
Cryptographic modules generate the certain class of critical security parameters such as a secret
key using a random bit generator within the modules. Such modules can store generated security
parameters in embedded non-volatile memory elements. For higher security, a combination of tamper
response and zeroization techniques may be used for protecting stored security parameters from active
unauthorized attempts of accessing such parameters. However, as the reverse-engineering technology
advances, the risk of theft of such stored security parameters has become higher than ever.
The rapidly pervading technology called a PUF is promising to mitigate the above-mentioned risks
by enabling security parameter management without storing such parameters. PUFs are hardware-
based functions providing steadiness and randomness of their outputs and physical and mathematical
unclonability of the functions themselves, taking advantage of intrinsic subtle variations in the device’s
physical properties, which are also considered object’s fingerprints. PUFs can be used for security
parameter generation (e.g. key, initialization vector, nonce and seed), entity authentication or device
identification in cryptographic modules.
Now, security requirements of PUFs should be considered at system level, meaning that they should
consider many possible attack paths, as detailed further in this document.
The purpose of this document is to define the security requirements of batches of PUFs and of single
instances of PUF for assuring an adequate level of quality of the provided PUFs in cryptographic
modules. This document is meant to be used for the following purposes.
a) In the procurement process of a PUF-equipped product, the procurement body specifies the security
requirements of the PUF in accordance with this document. The product vendor evaluates the
PUF whether the PUF satisfies all the specified security requirements, and reports the evaluation
results to the procurement body.
b) The vendors evaluate the security of their PUF, publicize the evaluation results and clarify the
security of their PUF.
It should be noted that all of the security requirements defined in this document are not necessarily
quantitatively evaluable.
This document is related to ISO/IEC 19790 which specifies security requirements for cryptographic
modules. In those modules, CSPs (e.g. key) and PSPs [e.g. identifier (ID)] are the assets to protect.
PUF is one solution to avoid storing security parameters, thereby increasing the overall security of a
cryptographic module.
© ISO/IEC 2020 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 20897-1:2020(E)
Information security, cybersecurity and privacy
protection — Physically unclonable functions —
Part 1:
Security requirements
1 Scope
This document specifies the security requirements for physically unclonable functions (PUFs). Specified
security requirements concern the output properties, tamper-resistance and unclonability of a single
and a batch of PUFs. Since it depends on the application which security requirements a PUF needs to
meet, this documents also describes the typical use cases of a PUF.
Amongst PUF use cases, random number generation is out of scope in this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 18031, Information technology — IT Security techniques — Random bit generation
ISO/IEC 19790, Information technology — Security techniques — Security requirements for
cryptographic modules
3 Terms and definitions
For the purposes of this document, terms and definitions given in ISO/IEC 18031, ISO/IEC 19790 and
the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
challenge
variable parameters input to a PUF
Note 1 to entry: Some type of PUFs do not take an input challenge, and such PUFs are called a no-challenge PUF. A
no-challenge PUF can be seen as a special type of PUF where a challenge length is 0 bit (see 3.9).
3.2
confined PUF
DEPRECATED: weak PUF
PUF that has a limited space of challenge-response pairs
Note 1 to entry: The term “weak PUF” does not properly express the characteristics of the PUF; nonetheless, it is
the way this category of PUFs is referred to in the scientific literature.
© ISO/IEC 2020 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC 20897-1:2020(E)
3.3
extensive PUF
DEPRECATED: strong PUF
PUF that has so large space of challenge-response pairs that not all addresses cannot be read out within
the attack time scales and its entire function cannot be modelled in extenso from the knowledge of few
challenge/response pairs on a different device (e.g. a general purpose processor)
3.4
false acceptance rate
FAR
probability that the inter-distance is smaller than or equal to the set threshold
Note 1 to entry: FAR is equivalent to the evaluation of the cumulative distribution function of the inter-distance
at the set threshold.
3.5
false rejection rate
FRR
probability that the intra-distance is larger than the set threshold
Note 1 to entry: FRR is equivalent to the complement of the evaluation of the cumulative distribution function of
the intra-distance at the set threshold.
3.6
fuzzy extractor
scheme to recover the original data from noisy data using error-correcting technique
Note 1 to entry: Fuzzy extractor uses a pair of algorithms; the first one generates a helper string from original
data, and the second one recovers the original data from noisy data using error correcting techniques and the
helper string.
3.7
inter-Hamming distance
inter-HD
Hamming distance between the two responses obtained by giving the identical challenges to two
different PUFs or obtained from two different no-challenge PUFs
3.8
intra-Hamming distance
intra-HD
Hamming distance between the two responses obtained by giving the same challenge twice to the same
PUF or obtained from the same no-challenge PUF
3.9
no-challenge PUF
one form of a confined PUF that does not receive a challenge as an input
3.10
physically unclonable function
physical unclonable function
PUF
function implemented in a device that is produced or configured with the security objective that
random fluctuations in the production process lead to different behaviours and are hard to reproduce
physically
3.11
response
output value from a PUF
2 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 20897-1:2020(E)
3.12
static entropy source
source of entropy which is prepared in advance of its use
4 Abbreviated terms
CRP challenge response pair
CSP critical security parameter
DFA differential fault analysis
DRBG deterministic random bit generator
ECC error correction code
FIB focused ion beam
HCI hot carrier injection
HMAC hash-based message authentication code
LVP laser voltage probing
MOS metal oxide semiconductor
NBTI negative bias temperature instability
PSP public security parameter
PUF physically unclonable function
5 Security requirements for PUFs
5.1 General
A PUF is a physical object that provides a unique digital output as a (deterministic) function of the given
inputs. The mapping between the inputs and outputs of a PUF is determined by the variation of device
components (e.g. transistor, wire, capacitance) arisen during manufacturing process, etc. Since the
device variation is random and uncontrollable, it is virtually impossible to manufacture two PUFs that
behave in exactly the same way. Actually, the idea behind a PUF is that given the identical “blueprint”
or fabrication file, every instance behaves differently. Therefore, the PUF may be used for security
parameter generation, device identification and device authentication.
A PUF’s output is expected to be random for different challenges and for inter-modules. Another
random sequence or key to be generated from a PUF should not be estimated from any other output of
the PUF. In order to keep using the same generated key, the same challenge only has to be kept. Even
if a challenge is leaked out, the corresponding response should not be estimated without having the
same device activated. However, for those purposes, particular caution should be taken due to the PUF’s
properties. The raw output of a PUF contains a small amount of errors due to subtle fluctuations in the
physical properties exploited. Therefore, typically an error correction scheme is combined with the
output of a PUF in order to make the output the same every time the same challenge is given. In order
to avoid undesired regeneration of the same key or nonce, it is required to maintain the challenge value
carefully.
A PUF and DRBG are different in the following two aspects:
— an output of a DRBG is completely computable by a deterministic algorithm given a seed, whereas a
response of a PUF is virtually impossible to compute from a challenge;
© ISO/IEC 2020 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC 20897-1:2020(E)
— different instances of a DRBG will produce completely the same outputs given the same seed,
whereas different PUFs will output different responses.
Therefore, the application of a PUF for random number generation is out of scope in this document.
A PUF is seen as an instance of a design by a factory (which can be modelled as a random variable).
Ideally, the properties of each PUF instance are independent and identically distributed (i.i.d.), as
represented in Figure 1. Notice that, in practice, the PUFs are neither identical nor independent: it is the
purpose of some security requirements to quantify how well PUF instances differ one from each other.
For the PUF to indeed provide a securely strong and reliable response, some properties shall be met.
This clause concerns the definition of the security requirements which apply irrespective of PUF
implementation, whereas there exist many kinds of PUF implementations (refer to Annex A).
Figure 1 — (Ideal) modelization of a PUF as a random instance from a factory
5.2 PUF interface
Generally, a PUF receives an input called a challenge, and generates a unique output called a response.
A challenge is a bit-string made up of challengeLength bits, and a response is a bit-string made up of
responseLength bits. The response may be specific to an input challenge. In case of a no-challenge
PUF, the challenge length is considered as 0 bit. Thus, a PUF can be an alternative to a memory of
challengeLength
2 words where each word is responseLength bits.
A PUF may have optional ports, which allow for security testing. The signals from these ports are output
status, and are meant to indicate whether the PUF responses can be used securely. After the security
test is finished, these ports shall be disabled to avoid being exploited by an attacker.
In addition, a PUF may have other optional ports to control the PUF.
5.3 PUF building blocks
A PUF consists of a main block and an optional pre-processing block and post-processing block. The
structure of a PUF is illustrated in Figure 2.
4 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 20897-1:2020(E)
Figure 2 — Functional model of a PUF with analogue output measure from the static
entropy source
The main block extracts the device variation and generates a unique output to the PUF. A main block
consists of an entropy source and an entropy extractor. Some examples are given in Annex B.
The entropy source of a PUF is the device variation arisen during manufacturing process and so forth.
The device variation is stationary when in use, and therefore the entropy source of a PUF is called a
static entropy source.
The entropy extractor is a mechanism that digitize the analogue quantity generated from the
entropy source.
Since the PUF responses are generated from the subtle device variation, the responses are sensitive
to noise and often include erroneous bits. The optional pre-processing block is used to improve the
steadiness of the responses.
One solution to improve the steadiness is to discard unstable CRPs. In Figure 2, to increase the
steadiness, some function can be applied to the challenges, e.g. to mask unreliable elements amongst the
"n" individual entropic elements making up the PUF. Another solution is to apply ECC to the responses.
The pre-processing block generates helper data that is subsequently used to correct the error bits.
The optional post-processing block also improves the steadiness of the PUF responses. The decoding
block applies majority voting or ECC decoding to correct the error bits in the responses.
Another purpose of the post-processing is to eliminate bias in the responses. The output distribution
of a PUF can be equalized by removing bias by implementing a Boolean function with good diffusion
[1]
properties .
Note that in Figure 2, the two optional blocks "decoding block" and "debias block" may, under certain
[2]
circumstances, be merged or swapped (as in Von Neumann debiasing or Index Based Syndrome
debiasing). Because the post-processing can leak entropy, the post-processing should be carefully
analysed.
5.4 Use cases of PUF
5.4.1 Security parameter generation
One usage consists in using PUF outputs as security parameters such as cryptographic keys,
nonces, seeds for random number generators, etc. Figure 3 shows the example block diagram of the
cryptographic key generation with a confined PUF.
While a non-volatile memory virtually permanently stores a secret, a confined PUF generates a volatile
secret. To use a PUF for security parameter generation, the PUF is required to output an identical
response to the given challenge with a small bit error.
© ISO/IEC 2020 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC 20897-1:2020(E)
An extensive PUF, which indeed has a challenge input, can be used equivalently as a confined PUF if it
uses a constant challenge set.
Generally, a response of a PUF is sensitive to noise. Therefore, the error correction scheme called the
fuzzy extractor is usually necessary to use a PUF for security parameter generation. The fuzzy extractor
usually requires the redundant information called the helper data.
Figure 3 — Example of the security parameter generation with a confined PUF
5.4.2 Device identification
The second usage consists in device unfalsifiable identification. In this case, a PUF is used as a public
identifier, which, therefore, shall not be cloned, nor falsified. An example of this use case is prevention
of the intentional over-production of silicon chips. Without an unfalsifiable and unclonable identifier,
a dishonest manufacturer can possibly overproduce chips and sell them as genuine. Manufacturing
silicon chips with a PUF, the over-produced chips may not be recognized as genuine due to the unique
and unfalsifiable identifier.
5.4.3 Device authentication
The third usage consists in authentication of a device. This application is demanding more security than
the plain identification, as the protocol shall be protected against replay attacks. Therefore, in this use
case, a subset of PUF’s challenges and responses is saved and this whitelist enables future interactive
attestation that the device is genuine. The scenario is referred to as challenge-response protocol.
Figure 4 shows the example of the PUF-based challenge-response authentication (hereinafter, simply
a “challenge-response authentication”) using an extensive PUF. The challenge-response authentication
has two phases called the enrolment and verification.
In the enrolment phase, the verifier collects the CRPs of the PUFs to be verified and record them to
a database. The CRPs are associated with the ID of the PUF. The enrolment is performed in a secure
environment by a trusted player, e.g. a manufacturer, vendor and service provider.
After the enrolment, products equipped with a PUF are shipped and delivered to a user. Then the
verification is performed in the field by request from a verifier. In this example, the communication
channel is not encrypted, and hence the challenge, C, is supposed to be used only once to avoid a
replay attack.
In the verification phase:
a) a user of the PUF sends the PUF ID to the verifier;
6 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 20897-1:2020(E)
b) the verifier takes challenge, C, from the database and sends it to the user;
c) the user inputs the challenge, C, to the PUF and obtains the response, R’;
d) the user sends the response, R’, to the verifier;
e) the verifier collates the returned response, R’, and recorded response, R, in the database;
f) if R = R’, the PUF is authenticated.
Because responses of a PUF usually include erroneous bits, authentication is performed based on the
fuzzy identification scheme with a threshold. In the fuzzy identification, a PUF is authenticated when
the Hamming distance of R and R’ is less than the set threshold. If the intra-HD and inter-HD of a PUF are
separately distributed, the PUF is perfectly identifiable, and therefore authenticated. If the distribution
of the intra-HD and inter-HD are overlapped, FAR and/or FRR is not zero, and therefore, identification
error occurs (see Figure 5).
Figure 4 — Example of the challenge-response authentication with an extensive PUF
Figure 5 — Distributions of the intra-HD and inter-HD
© ISO/IEC 2020 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/IEC 20897-1:2020(E)
5.5 Security requirements
5.5.1 General
This subclause defines the security requirements which a PUF shall satisfy for the security purposes:
steadiness (5.5.2), randomness (5.5.3), uniqueness (5.5.4), tamper-resistance (5.5.5), mathematical
unclonability (5.5.6) and physical unclonability (5.5.7).
For the purpose of this document, the responses from multiple PUFs are arranged into a cube as shown
in Figure 6. The repetitive calls to a PUF are illustrated in Figure 7. The single small cube describes a
1-bit response from a PUF. The three axes of the cube and the time are described as directions:
— direction B: “#bits” shows the bit length of the response obtained from a single challenge. In a 1-bit
response PUF, e.g. arbiter PUF, the dimension B collapses.
— direction C: “#challenges” shows the number of different challenges given to a PUF. In a no-challenge
PUF (or, more rigorously, a one-challenge PUF), e.g. SRAM PUF, the dimension C collapses.
— direction D: “#PUF” shows the number of different PUF devices under test.
— direction T: “#query” shows the number of query iterations under the fixed PUF device and challenge.
Figure 6 — Cube representation of the response sequences from multiple PUFs
Figure 7 — Responses obtained by repetitive calls to the PUFs.
8 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC 20897-1:2020(E)
5.5.2 Steadiness
If a PUF is used for security parameter generation, device identification and device authentication, the
PUF shall satisfy steadiness. Steadiness is the property that the response of the PUF is (almost) always
the same if the same challenge is repeatedly given, irrespective of external manipulation (within the
allowed environmental conditions specified by the PUF). External manipulations are:
— repetition of queries; either due to a method to increase the steadiness, or due to the reboot of the
system, which requests the same response at each boot;
— variation of the environment within the range of allowed values.
5.5.3 Randomness
If a PUF is used for security parameter generation and device authentication, the PUF shall satisfy
randomness. Randomness is interpreted as the entropy of the responses in the B-C plain in Figure 6.
5.5.4 Uniqueness
If a PUF is used for security parameter generation, device identification and device authentication, the
PUF shall satisfy the uniqueness. Uniqueness is the inter-PUF property that for any
...
FINAL
INTERNATIONAL ISO/IEC
DRAFT
STANDARD FDIS
20897-1
ISO/IEC JTC 1/SC 27
Information security, cybersecurity
Secretariat: DIN
and privacy protection — Physically
Voting begins on:
2020-09-18 unclonable functions —
Voting terminates on:
Part 1:
2020-11-13
Security requirements
RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/IEC FDIS 20897-1:2020(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
©
NATIONAL REGULATIONS. ISO/IEC 2020
---------------------- Page: 1 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 3
5 Security requirements for PUFs . 3
5.1 General . 3
5.2 PUF interface . 4
5.3 PUF building blocks . 4
5.4 Use cases of PUF . 5
5.4.1 Security parameter generation . 5
5.4.2 Device identification . 6
5.4.3 Device authentication . 6
5.5 Security requirements . 8
5.5.1 General. 8
5.5.2 Steadiness . 9
5.5.3 Randomness. 9
5.5.4 Uniqueness. 9
5.5.5 Tamper-resistance . 9
5.5.6 Mathematical unclonability . 9
5.5.7 Physical unclonability. 9
5.6 Mapping between security requirements and use cases .10
Annex A (informative) Classification of PUF .12
Annex B (informative) Some PUF implementations .13
Annex C (informative) PUF life-cycle .15
Bibliography .16
© ISO/IEC 2020 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/ patents) or the IEC
list of patent declarations received (see http:// patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www .iso .org/ iso/ foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
A list of all parts in the ISO/IEC 20897 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
iv © ISO/IEC 2020 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
Introduction
This document specifies the security requirements for physically unclonable functions (PUFs) for
generating non-stored cryptographic parameters.
Cryptographic modules generate the certain class of critical security parameters such as a secret
key using a random bit generator within the modules. Such modules can store generated security
parameters in embedded non-volatile memory elements. For higher security, a combination of tamper
response and zeroization techniques may be used for protecting stored security parameters from active
unauthorized attempts of accessing such parameters. However, as the reverse-engineering technology
advances, the risk of theft of such stored security parameters has become higher than ever.
The rapidly pervading technology called a PUF is promising to mitigate the above-mentioned risks
by enabling security parameter management without storing such parameters. PUFs are hardware-
based functions providing steadiness and randomness of their outputs and physical and mathematical
unclonability of the functions themselves, taking advantage of intrinsic subtle variations in the device’s
physical properties, which are also considered object’s fingerprints. PUFs can be used for security
parameter generation (e.g. key, initialization vector, nonce and seed), entity authentication or device
identification in cryptographic modules.
Now, security requirements of PUFs should be considered at system level, meaning that they should
consider many possible attack paths, as detailed further in this document.
The purpose of this document is to define the security requirements of batches of PUFs and of single
instances of PUF for assuring an adequate level of quality of the provided PUFs in cryptographic
modules. This document is meant to be used for the following purposes.
a) In the procurement process of a PUF-equipped product, the procurement body specifies the security
requirements of the PUF in accordance with this document. The product vendor evaluates the
PUF whether the PUF satisfies all the specified security requirements, and reports the evaluation
results to the procurement body.
b) The vendors evaluate the security of their PUF, publicize the evaluation results and clarify the
security of their PUF.
It should be noted that all of the security requirements defined in this document are not necessarily
quantitatively evaluable.
This document is related to ISO/IEC 19790 which specifies security requirements for cryptographic
modules. In those modules, CSPs (e.g. key) and PSPs (e.g. ID) are the assets to protect. PUF is one solution
to avoid storing security parameters, thereby increasing the overall security of a cryptographic module.
© ISO/IEC 2020 – All rights reserved v
---------------------- Page: 5 ----------------------
FINAL DRAFT INTERNATIONAL STANDARD ISO/IEC FDIS 20897-1:2020(E)
Information security, cybersecurity and privacy
protection — Physically unclonable functions —
Part 1:
Security requirements
1 Scope
This document specifies the security requirements for physically unclonable functions (PUFs). Specified
security requirements concern the output properties, tamper-resistance and unclonability of a single
and a batch of PUFs. Since it depends on the application which security requirements a PUF needs to
meet, this documents also describes the typical use cases of a PUF.
Amongst PUF use cases, random number generation is out of scope in this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 18031, Information technology — IT Security techniques — Random bit generation
ISO/IEC 19790, Information technology — Security techniques — Security requirements for
cryptographic modules
3 Terms and definitions
For the purposes of this document, terms and definitions given in ISO/IEC 18031, ISO/IEC 19790 and
the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
challenge
variable parameters input to a PUF
Note 1 to entry: Some type of PUFs do not take an input challenge, and such PUFs are called a no-challenge PUF. A
no-challenge PUF can be seen as a special type of PUF where a challenge length is 0 bit (see 3.10).
3.2
confined PUF
DEPRECATED: weak PUF
PUF that has a limited space of challenge-response pairs
Note 1 to entry: The term “weak PUF” does not properly express the characteristics of the PUF; nonetheless, it is
the way this category of PUFs is referred to in the scientific literature.
© ISO/IEC 2020 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
3.3
entropy source
component, device or event which produces outputs which, when captured and processed in some way,
produce a bit string containing entropy
[SOURCE: ISO/IEC 18031:2011, 3.12]
3.4
extensive PUF
DEPRECATED: strong PUF
PUF that has so large space of challenge-response pairs that not all addresses cannot be read out within
the attack time scales and its entire function cannot be modelled in extenso from the knowledge of few
challenge/response pairs on a different device (e.g. a general purpose processor)
3.5
false acceptance rate
FAR
probability that the inter-distance is smaller than or equal to the set threshold
Note 1 to entry: FAR is equivalent to the evaluation of the cumulative distribution function of the inter-distance
at the set threshold.
3.6
false rejection rate
FRR
probability that the intra-distance is larger than the set threshold
Note 1 to entry: FRR is equivalent to the complement of the evaluation of the cumulative distribution function of
the intra-distance at the set threshold.
3.7
fuzzy extractor
scheme to recover the original data from noisy data using error-correcting technique
Note 1 to entry: Fuzzy extractor uses a pair of algorithms; the first one generates a helper string from original
data, and the second one recovers the original data from noisy data using error correcting techniques and the
helper string.
3.8
intra-Hamming distance
intra-HD
Hamming distance between the two responses obtained by giving the same challenge twice to the same
PUF or obtained from the same no-challenge PUF
3.9
inter-Hamming distance
inter-HD
Hamming distance between the two responses obtained by giving the identical challenges to two
different PUFs or obtained from two different no-challenge PUFs
3.10
no-challenge PUF
one form of a confined PUF that does not receive a challenge as an input
3.11
physically unclonable function
physical unclonable function
PUF
function implemented in a device that is produced or configured with the security objective that
random fluctuations in the production process lead to different behaviours and are hard to reproduce
physically
2 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
3.12
response
output value from a PUF
3.13
static entropy source
source of entropy which is prepared in advance of its use
4 Abbreviated terms
CRP challenge response pair
CSP critical security parameter
DFA differential fault analysis
DRBG deterministic random bit generator
ECC error correction code
FIB focused ion beam
HCI hot carrier injection
HMAC hash-based message authentication code
LVP laser voltage probing
MOS metal oxide semiconductor
NBTI negative bias temperature instability
PSP public security parameter
PUF physically unclonable function
5 Security requirements for PUFs
5.1 General
A PUF is a physical object that provides a unique digital output as a (deterministic) function of the given
inputs. The mapping between the inputs and outputs of a PUF is determined by the variation of device
components (e.g. transistor, wire, capacitance) arisen during manufacturing process, etc. Since the
device variation is random and uncontrollable, it is virtually impossible to manufacture two PUFs that
behave in exactly the same way. Actually, the idea behind a PUF is that given the identical “blueprint”
or fabrication file, every instance behaves differently. Therefore, the PUF may be used for security
parameter generation, device identification and device authentication.
A PUF’s output is expected to be random for different challenges and for inter-modules. Another
random sequence or key to be generated from a PUF should not be estimated from any other output of
the PUF. In order to keep using the same generated key, the same challenge only has to be kept. Even
if a challenge is leaked out, the corresponding response should not be estimated without having the
same device activated. However, for those purposes, particular caution should be taken due to the PUF’s
properties. The raw output of a PUF contains a small amount of errors due to subtle fluctuations in the
physical properties exploited. Therefore, typically an error correction scheme is combined with the
output of a PUF in order to make the output the same every time the same challenge is given. In order
to avoid undesired regeneration of the same key or nonce, it is required to maintain the challenge value
carefully.
© ISO/IEC 2020 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
A PUF and DRBG are different in the following two aspects:
— an output of a DRBG is completely computable by a deterministic algorithm given a seed, whereas a
response of a PUF is virtually impossible to compute from a challenge;
— different instances of a DRBG will produce completely the same outputs given the same seed,
whereas different PUFs will output different responses.
Therefore, the application of a PUF for random number generation is out of scope in this document.
A PUF is seen as an instance of a design by a factory (which can be modelled as a random variable).
Ideally, the properties of each PUF instance are independent and identically distributed (i.i.d.), as
represented in Figure 1. Notice that, in practice, the PUFs are neither identical nor independent: it is the
purpose of some security requirements to quantify how well PUF instances differ one from each other.
For the PUF to indeed provide a securely strong and reliable response, some properties shall be met.
This clause concerns the definition of the security requirements which apply irrespective of PUF
implementation, whereas there exist many kinds of PUF implementations (refer to Annex A).
Figure 1 — (Ideal) modelization of a PUF as a random instance from a factory
5.2 PUF interface
Generally, a PUF receives an input called a challenge, and generates a unique output called a response.
A challenge is a bit-string made up of challengeLength bits, and a response is a bit-string made up of
responseLength bits. The response may be specific to an input challenge. In case of a no-challenge
PUF, the challenge length is considered as 0 bit. Thus, a PUF can be an alternative to a memory of
challengeLength
2 words where each word is responseLength bits.
A PUF may have optional ports, which allow for security testing. The signals from these ports are output
status, and are meant to indicate whether the PUF responses can be used securely. After the security
test is finished, these ports shall be disabled to avoid being exploited by an attacker.
In addition, a PUF may have other optional ports to control the PUF.
5.3 PUF building blocks
A PUF consists of a main block and an optional pre-processing block and post-processing block. The
structure of a PUF is illustrated in Figure 2.
4 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
Figure 2 — Functional model of a PUF with analogue output measure from the static
entropy source
The main block extracts the device variation and generates a unique output to the PUF. A main block
consists of an entropy source and an entropy extractor. Some examples are given in Annex B.
The entropy source of a PUF is the device variation arisen during manufacturing process and so forth.
The device variation is stationary when in use, and therefore the entropy source of a PUF is called a
static entropy source.
The entropy extractor is a mechanism that digitize the analogue quantity generated from the
entropy source.
Since the PUF responses are generated from the subtle device variation, the responses are sensitive
to noise and often include erroneous bits. The optional pre-processing block is used to improve the
steadiness of the responses.
One solution to improve the steadiness is to discard unstable CRPs. In Figure 2, to increase the
steadiness, some function can be applied to the challenges, e.g. to mask unreliable elements amongst the
"n" individual entropic elements making up the PUF. Another solution is to apply ECC to the responses.
The pre-processing block generates helper data that is subsequently used to correct the error bits.
The optional post-processing block also improves the steadiness of the PUF responses. The decoding
block applies majority voting or ECC decoding to correct the error bits in the responses.
Another purpose of the post-processing is to eliminate bias in the responses. The output distribution
of a PUF can be equalized by removing bias by implementing a Boolean function with good diffusion
[1]
properties .
Note that in Figure 2, the two optional blocks "decoding block" and "debias block" may, under certain
[2]
circumstances, be merged or swapped (as in Von Neumann debiasing or Index Based Syndrome
debiasing). Because the post-processing can leak entropy, the post-processing should be carefully
analysed.
5.4 Use cases of PUF
5.4.1 Security parameter generation
One usage consists in using PUF outputs as security parameters such as cryptographic keys,
nonces, seeds for random number generators, etc. Figure 3 shows the example block diagram of the
cryptographic key generation with a confined PUF.
While a non-volatile memory virtually permanently stores a secret, a confined PUF generates a volatile
secret. To use a PUF for security parameter generation, the PUF is required to output an identical
response to the given challenge with a small bit error.
© ISO/IEC 2020 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
An extensive PUF, which indeed has a challenge input, can be used equivalently as a confined PUF if it
uses a constant challenge set.
Generally, a response of a PUF is sensitive to noise. Therefore, the error correction scheme called the
fuzzy extractor is usually necessary to use a PUF for security parameter generation. The fuzzy extractor
usually requires the redundant information called the helper data.
Figure 3 — Example of the security parameter generation with a confined PUF
5.4.2 Device identification
The second usage consists in device unfalsifiable identification. In this case, a PUF is used as a public
identifier, which, therefore, shall not be cloned, nor falsified. An example of this use case is prevention
of the intentional over-production of silicon chips. Without an unfalsifiable and unclonable identifier,
a dishonest manufacturer can possibly overproduce chips and sell them as genuine. Manufacturing
silicon chips with a PUF, the over-produced chips may not be recognized as genuine due to the unique
and unfalsifiable identifier.
5.4.3 Device authentication
The third usage consists in authentication of a device. This application is demanding more security than
the plain identification, as the protocol shall be protected against replay attacks. Therefore, in this use
case, a subset of PUF’s challenges and responses is saved and this whitelist enables future interactive
attestation that the device is genuine. The scenario is referred to as challenge-response protocol.
Figure 4 shows the example of the PUF-based challenge-response authentication (hereinafter, simply
a “challenge-response authentication”) using an extensive PUF. The challenge-response authentication
has two phases called the enrolment and verification.
In the enrolment phase, the verifier collects the CRPs of the PUFs to be verified and record them to
a database. The CRPs are associated with the ID of the PUF. The enrolment is performed in a secure
environment by a trusted player, e.g. a manufacturer, vendor and service provider.
After the enrolment, products equipped with a PUF are shipped and delivered to a user. Then the
verification is performed in the field by request from a verifier. In this example, the communication
channel is not encrypted, and hence the challenge, C, is supposed to be used only once to avoid a
replay attack.
In the verification phase:
a) a user of the PUF sends the PUF ID to the verifier;
6 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
b) the verifier takes challenge, C, from the database and sends it to the user;
c) the user inputs the challenge, C, to the PUF and obtains the response, R’;
d) the user sends the response, R’, to the verifier;
e) the verifier collates the returned response, R’, and recorded response, R, in the database;
f) if R = R’, the PUF is authenticated.
Because responses of a PUF usually include erroneous bits, authentication is performed based on the
fuzzy identification scheme with a threshold. In the fuzzy identification, a PUF is authenticated when
the Hamming distance of R and R’ is less than the set threshold. If the intra-HD and inter-HD of a PUF are
separately distributed, the PUF is perfectly identifiable, and therefore authenticated. If the distribution
of the intra-HD and inter-HD are overlapped, FAR and/or FRR is not zero, and therefore, identification
error occurs (see Figure 5).
Figure 4 — Example of the challenge-response authentication with an extensive PUF
Figure 5 — Distributions of the intra-HD and inter-HD
© ISO/IEC 2020 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
5.5 Security requirements
5.5.1 General
This subclause defines the security requirements which a PUF shall satisfy for the security purposes:
steadiness (5.5.2), randomness (5.5.3), uniqueness (5.5.4), tamper-resistance (5.5.5), mathematical
unclonability (5.5.6) and physical unclonability (5.5.7).
For the purpose of this document, the responses from multiple PUFs are arranged into a cube as shown
in Figure 6. The repetitive calls to a PUF are illustrated in Figure 7. The single small cube describes a
1-bit response from a PUF. The three axes of the cube and the time are described as directions:
— direction B: “#bits” shows the bit length of the response obtained from a single challenge. In a 1-bit
response PUF, e.g. arbiter PUF, the dimension B collapses.
— direction C: “#challenges” shows the number of different challenges given to a PUF. In a no-challenge
PUF (or, more rigorously, a one-challenge PUF), e.g. SRAM PUF, the dimension C collapses.
— direction D: “#PUF” shows the number of different PUF devices under test.
— direction T: “#query” shows the number of query iterations under the fixed PUF device and challenge.
Figure 6 — Cube representation of the response sequences from multiple PUFs
Figure 7 — Responses obtained by repetitive calls to the PUFs.
8 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC FDIS 20897-1:2020(E)
5.5.2 Steadiness
If a PUF is used for security parameter generation, device identification and device authentication, the
PUF shall satisfy steadiness. Steadiness is the property that the response of the PUF is (almost) always
the same if the same challenge is repeatedly given, irrespective of external manipulation (within the
allowed environmental conditions specified
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.