ISO/IEC 23264-2:2024
(Main)Information security — Redaction of authentic data — Part 2: Redactable signature schemes based on asymmetric mechanisms
Information security — Redaction of authentic data — Part 2: Redactable signature schemes based on asymmetric mechanisms
This document specifies cryptographic mechanisms to redact authentic data. The mechanisms described in this document offer different combinations of the security properties defined and described in ISO/IEC 23264-1. For all mechanisms, this document describes the processes for key generation, generating the redactable attestation, carrying out redactions and verifying redactable attestations. This document contains mechanisms that are based on asymmetric cryptography using three related transformations: ¾ a public transformation defined by a verification key (verification process for verifying a redactable attestation), ¾ a private transformation defined by a private attestation key (redactable attestation process for generating a redactable attestation), and ¾ a third transformation defined by the redaction key (redaction process) allowing to redact authentic information within the constraints set forth during generation of the attestation such that redacted information cannot be reconstructed. This document contains mechanisms which, after a successful redaction, allow the attestation to remain verifiable using the verification transformation and attest that non-redacted fields of the attested message are unmodified. This document further details that the three transformations have the property whereby it is computationally infeasible to derive the private attestation transformation, given the redaction and or the verification transformation and key(s).
Sécurité de l'information — Rédaction de données authentifiées — Partie 2: Schémas de signature éditable basés sur des mécanismes asymétriques
General Information
Standards Content (Sample)
International
Standard
ISO/IEC 23264-2
First edition
Information security — Redaction
2024-08
of authentic data —
Part 2:
Redactable signature schemes
based on asymmetric mechanisms
Sécurité de l'information — Rédaction de données
authentifiées —
Partie 2: Schémas de signature éditable basés sur des mécanismes
asymétriques
Reference number
© ISO/IEC 2024
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
© ISO/IEC 2024 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and conventions . 3
4.1 Symbols .3
4.2 Conventions .4
5 General . 5
6 Generic construction from signature schemes and hash-functions . 5
6.1 Parameters .5
6.2 Construction .6
6.2.1 Key generation process .6
6.2.2 Redactable attestation process .6
6.2.3 Redaction process .7
6.2.4 Verification process .8
7 Scheme SBZ02-MERSAProd . 8
7.1 Parameters .8
7.2 Construction .9
7.2.1 Key generation process .9
7.2.2 Redactable attestation process .9
7.2.3 Redaction process .10
7.2.4 Verification process .11
8 Scheme BBDFFKMOPPS10 .12
8.1 Parameters . 12
8.2 Construction . 12
8.2.1 Key generation process . 12
8.2.2 Redactable attestation process . 12
8.2.3 Redaction process .14
8.2.4 Verification process . 15
9 Scheme DPSS15 . 17
9.1 Parameters .17
9.2 Subroutine: RSA Accumulators .17
9.3 Construction .18
9.3.1 Key generation process .18
9.3.2 Redactable attestation process .19
9.3.3 Redaction process . 20
9.3.4 Verification Process . 20
10 Scheme MHI06 .21
10.1 Parameters .21
10.2 Construction . 22
10.2.1 Key generation process . 22
10.2.2 Redactable attestation process . 22
10.2.3 Redaction process . 23
10.2.4 Verification Process .24
11 Scheme MIMSYTI05 .25
11.1 Parameters . 25
11.2 Construction . 25
11.2.1 Key generation process . 25
11.2.2 Redactable attestation process . 25
© ISO/IEC 2024 – All rights reserved
iii
11.2.3 Redaction process . 26
11.2.4 Verification Process .27
Annex A (normative) Object identifiers .29
Annex B (informative) Overview of properties of redactable signature schemes based on
asymmetric mechanisms .30
Annex C (informative) Criteria for inclusion of schemes in this document .33
Annex D (informative) Numerical examples .34
Bibliography .57
© ISO/IEC 2024 – All rights reserved
iv
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 or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
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.
In the IEC, see www.iec.ch/understanding-standards.
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 23264 series can be found on the ISO and IEC websites.
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 and
www.iec.ch/national-committees.
© ISO/IEC 2024 – All rights reserved
v
Introduction
This document specifies cryptographic mechanisms to redact authentic data where the redactable
attestation scheme is based on asymmetric mechanisms.
Attestation schemes, in particular digital signature schemes or message authentication codes, can be used to
provide data integrity and data origin authentication. Redactable attestation can be used to blank out parts,
herein called fields, of an attested message without invalidating the attestation on the remaining contents
of the message. This redaction process requires a redaction key. The redaction key computationally does
not reveal the attestation key, by which schemes can allow for public redactions. Any other modification
of the document (e.g. redaction of other message parts, or insertion/modification of any parts) will
invalidate the attestation. Schemes can have specific additional security properties, which are described in
ISO/IEC 23264-1. The achievable properties for each scheme are stated in this document.
Redactable attestation schemes are a basic building block in many privacy-preserving applications, such
as privacy-preserving data sharing or authentication, where a party may decide to forward only necessary
information to a receiver, while the latter is still assured that the received information was previously
attested, for example, by a public authority.
The objective of the ISO/IEC 23264 series is to remedy existing incompatibilities or inconsistently defined
properties found in academic literature, and to ease the real-world adoption of this technology. Specifically,
the goal of this document is to focus on algorithms that enable the authenticity-preserving redaction of
general data structures like sets or ordered lists based on asymmetric cryptography. It adheres to the
common terminology and description of cryptographic properties for redactable attestation schemes given
in ISO/IEC 23264-1.
The ISO/IEC 23264 series complements ISO/IEC 27038, which specifies the redaction of digital documents
without considering the authenticity of the data.
This document contains the following algorithms based on asymmetric cryptography:
— generic construction from signature schemes and hash-functions
— scheme SBZ02-MERSAProd
— scheme BBDFFKMOPPS10
— scheme DPSS15
— scheme MHI06
— scheme MIMSYTI05
© ISO/IEC 2024 – All rights reserved
vi
International Standard ISO/IEC 23264-2:2024(en)
Information security — Redaction of authentic data —
Part 2:
Redactable signature schemes based on asymmetric
mechanisms
1 Scope
This document specifies cryptographic mechanisms to redact authentic data. The mechanisms described
in this document offer different combinations of the security properties defined and described in
ISO/IEC 23264-1. For all mechanisms, this document describes the processes for key generation, generating
the redactable attestation, carrying out redactions and verifying redactable attestations.
This document contains mechanisms that are based on asymmetric cryptography using three related
transformations:
— a public transformation defined by a verification key (verification process for verifying a redactable
attestation),
— a private transformation defined by a private attestation key (redactable attestation process for
generating a redactable attestation), and
— a third transformation defined by the redaction key (redaction process) allowing to redact authentic
information within the constraints set forth during generation of the attestation such that redacted
information cannot be reconstructed.
This document contains mechanisms which, after a successful redaction, allow the attestation to remain
verifiable using the verification transformation and attest that non-redacted fields of the attested message
are unmodified. This document further details that the three transformations have the property whereby it
is computationally infeasible to derive the private attestation transformation, given the redaction and or the
verification transformation and key(s).
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 23264-1, Information security — Redaction of authentic data — Part 1: General
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 23264-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
© ISO/IEC 2024 – All rights reserved
3.1
balanced tree
height-balanced tree
tree (3.13) in which the heights of the immediate subtrees of each node differ at most by one
[SOURCE: ISO/IEC 2382:2015, 2121638, modified — notes to entry have been removed.]
3.2
binary tree
ordered tree (3.13) in which each node has at most two other nodes that are directly subordinate
[SOURCE: ISO/IEC 2382:2015, 2121636, modified — notes to entry have been removed.]
3.3
balanced binary tree
binary tree (3.2) which is a balanced tree (3.1)
3.4
collision-resistant hash-function
hash-function (3.6) satisfying the following property: it is computationally infeasible to find any two distinct
inputs which map to the same output
Note 1 to entry: Computational feasibility depends on the specific security requirements and environment (see
ISO/IEC 10118-1:2016, Annex C).
[SOURCE: ISO/IEC 10118-1:2016, 3.1, modified — reference to ISO/IEC 10118-1:2016, Annex C has been
added in the note.]
3.5
hash-code
string of bits which is the output of a hash-function (3.6)
Note 1 to entry: The literature on this subject contains a variety of terms that have the same or similar meaning as
hash-code. Modification Detection Code, Manipulation Detection Code, digest, hash-result, hash-value and imprint are
some examples.
[SOURCE: ISO/IEC 10118-1:2016, 3.3]
3.6
hash-function
function which maps strings of bits of variable (but usually upper bounded) length to fixed-length strings of
bits, satisfying the following two properties:
— for a given output, it is computationally infeasible to find an input which maps to this output;
— for a given input, it is computationally infeasible to find a second input which maps to the same output
Note 1 to entry: Computational feasibility depends on the specific security requirements and environment. See
ISO/IEC 10118-1:2016, Annex C.
[SOURCE: ISO/IEC 10118-1:2016, 3.4, modified — reference to ISO/IEC 10118-1:2016, Annex C has been
added in the note.]
3.7
height
maximum number of nodes in any path leading from the root node (3.10) to a leaf node (3.8)
[SOURCE: ISO/IEC 2382:2015, 2121637, modified — “leaf node” has replaced "terminal node" in the
definition; notes to entry have been removed.]
© ISO/IEC 2024 – All rights reserved
3.8
leaf node
node that has no subordinate node (3.11)
[SOURCE: ISO/IEC 2382:2015, 2121489, modified — term "leaf node" has replaced the original terms "leaf"
and "terminal node".]
3.9
parent node
node to which at least one other node is directly subordinate
[SOURCE: ISO/IEC 2382:2015, 2121488, modified — notes to entry have been removed.]
3.10
root of a tree
root node
node of a tree (3.13) that has only subordinate nodes (3.11)
3.11
subordinate node
node at the other end of an outgoing arc; a node may have zero, one, or more subordinates
[SOURCE: ISO/IEC 9804:1998, 3.6.64]
3.12
subtree
part of a tree (3.13) including a node and all its subordinate nodes (3.11)
[SOURCE: ISO/IEC 2382:2015, 2121634, modified —notes to entry have been removed.]
3.13
tree
data structure containing nodes that are linked together hierarchically by oriented arcs with at most one
parent node for each node, and with only one root node (3.10)
[SOURCE: ISO/IEC 2382:2015, 2121633, modified – “by oriented arcs” has been added to the definition; notes
to entry have been removed.]
4 Symbols and conventions
4.1 Symbols
Throughout this document, the following symbols are used.
adm description of redacted or original admissible changes
adm′
description of redacted admissible changes
ak attestation key
att redactable or redacted attestation
att′
redacted attestation
m redacted or original message
m′
redacted message
mm,,…
individual field
1 n
© ISO/IEC 2024 – All rights reserved
mod description of modification instructions
n number of fields
pk public verification key used internally by asymmetric signature algorithm or ac-
cumulator scheme
rk redaction key
root
value assigned as content to the node forming the root of a tree
sk
secret signing key used internally by asymmetric signature algorithm or accumu-
lator scheme
tag
string used to mark messages or message fields
vk verification key
Z set of one or more domain parameters
Σ
output of a digital signature scheme as defined in ISO/IEC 14888-1
reject ,accept
output of a digital signature verification
4.2 Conventions
A triple of message, attestation, and admissible changes is denoted as (m, att, adm). In the same way a triple
of redacted message, a redacted attestation and redacted admissible changes is denoted by ( m′ , atta′′, dm ).
A specific value of a symbol sym is denoted as sym*, or sym** in order to differentiate their specific values.
An equality is stated using the equals sign =.
EXAMPLE 1 The statement that m*=m** means that the contents of m* are equal to the contents of m**.
The symbol || denotes a concatenation of strings.
When the symbol || is applied to values which are not represented as strings, the values are required to be
converted into a string before they are concatenated. See for example Reference [25] for a conversion of an
integer into a string.
The symbol a indicates the largest integer not exceeding a, following the definition of the floor function
specified in ISO/IEC 15444-1.
EXAMPLE 2 −24, 63=− , =0
The symbol ab/ denotes the result of the division of a by b.
This document uses set notation and symbols to denote set-like operations:
\ operation set minus, i.e. A \ B denotes the contents of set A without contents of set B
⋃ operation set union, i.e. A⋃B denotes all contents from set A together with those
of set B
⊆
statement sub set or equal, i.e. AB⊆denotes that all contents from set A are con-
tained as contents in set B
|A| denotes the size of the set A, i.e. the number of elements contained in A
∅ empty set
© ISO/IEC 2024 – All rights reserved
Where applicable, the output of a hash-function is interpreted as an integer.
5 General
This document adheres to the common terminology and description of cryptographic properties for
redactable attestation schemes given in ISO/IEC 23264-1.
Redactable attestation schemes provide data integrity and data origin authentication. While redactable
attestation can be used to allow a redactor to blank out parts, herein called fields, of an attested message
without invalidating the attestation on the remaining contents of the message, any other modification of the
document (e.g. redaction of other message parts, or insertion/modification of any parts) will invalidate the
attestation. This redaction process requires a redaction key. The redaction key computationally does not
reveal the attestation key, by which schemes can allow for redactions that are either public or by a party
other than the attestor. The verification key is cryptographically linked to the attestation key and allows
verification of the origin of the attested data.
The schemes can have specific additional security properties, which are described in ISO/IEC 23264-1. The
achievable properties for each scheme are stated in this document.
This document describes algorithms that enable the authenticity-preserving redaction of general data
structures like sets or ordered lists based on asymmetric cryptography.
This document contains the following algorithms based on asymmetric cryptography:
— Generic construction from signature schemes and hash-functions
— Scheme SBZ02-MERSAProd
— Scheme BBDFFKMOPPS10
— Scheme DPSS15
— Scheme MHI06
— Scheme MIMSYTI05
Finally, this document contains the following annexes:
— Annex A, which provides object identifiers which shall be used to identify the mechanisms defined in this
document.
— Annex B, which contains an overview of the different properties as defined and described in
ISO/IEC 23264-1 that are achieved by the different algorithms contained in this document.
— Annex C, which lists criteria for inclusion in this document.
— Annex D, which gives numerical examples to understand and check implementations of the algorithms
contained in this document.
6 Generic construction from signature schemes and hash-functions
6.1 Parameters
The generic construction makes use of the following parameters:
— digital signature scheme as defined in ISO/IEC 14888-1;
— collision-resistant hash-function Hash as defined in ISO/IEC 10118-1;
— security parameter λ .
© ISO/IEC 2024 – All rights reserved
The security parameter λ shall be met by all involved algorithms, especially for the hash-function and
digital signature scheme.
6.2 Construction
6.2.1 Key generation process
The key generation algorithm of the redactable attestation scheme consists of the following two procedures:
a) generate the set of domain parameters Z;
b) generate the attestation key ak, verification key vk and redaction key rk as follows:
1) use the key generation process of the digital signature scheme, such that the digital signature
scheme’s signature key serves as the attestation key ak,
2) use the digital signature scheme’s verification key as the verification key vk,
3) use the digital signature scheme’s verification key also as the redaction key rk, such that rk = vk.
The security parameter λ is taken into account such that the digital signature scheme offers at least the
indicated security strength.
6.2.2 Redactable attestation process
This process takes the following inputs:
— set of domain parameters Z
— attestation key ak
— message m consisting of n fields mm,,…
1 n
— admissible changes admn=…{}1, ,
The process Split() to split the message m into fields is generally out of scope of this document. However, the
process Split() shall be defined in such a way that fields can be transformed into the message and vice versa,
-1
in a reproducible way every time this conversion is necessary, i.e. if Split( m )= mm,,… then Split (
1 s
mm,,… ) = m . The scheme protects the content of each field and their order.
1 s
The process requires the generation of random data. Refer to ISO/IEC 18031 to generate this securely.
The process does not allow the specification of admissible changes, so by default all fields of the message (
mm,,… ) are admissible and can be redacted by anyone. In order to make this clear for the user, the input
1 n
for adm shall contain all field indices, i.e. admn=…1, , .
{}
The process is as follows:
[17]
a) Generate a Merkle tree as follows: Generate a binary tree which is also a balanced tree, henceforth
referred to as balanced binary tree, of sufficient height such that it has k leaf nodes with 2n> k ≥ n.
b) Choose a uniformly random λ -bit tag for the message; and choose n random λ -bit tags tag , one for
msg i
λ
each field of m. No tag shall contain only zeros, denoted as tag ≠ 0 .
i i
c) For each in=…1, , , compute the hash-code ht=Hash ag mtag using a collision-resistant
()
imsg ii
hash-function.
d) Initialize the Merkle tree using hh,,… as values for the n left-most leaf nodes of the balanced binary
1 n
tree, use the empty string for all remaining kn− leaf nodes.
© ISO/IEC 2024 – All rights reserved
e) Calculate the Merkle tree's root, denoted as root, using the collision-resistant hash-function Hash
by computing the value for each parent node in the tree as Hash (left-subordinate-node-value||right-
subordinate-node-value), where left-subordinate-node-value contains the value assigned to the left
subordinate node and right-subordinate-node-value contains the value of the right subordinate node.
f) Use the digital signature scheme’s signature process on inputs:
1) message: root ,tagn, ;
()
msg
2) set of domain parameters: Z;
3) signature key mapped from the attestation key: ak.
Receive as output the signature Σ .
The process outputs:
— redactable attestation attn=…Σ ,,tagt,,()ag ,tag
()
msgn1
6.2.3 Redaction process
This process takes the following inputs:
— set of domain parameters Z ;
— message m composed of n fields denoted as mm,,… ;
1 n
— redaction key rk ;
— admissible changes adm ;
— modification instructions mod that are in accordance with the admissible changes adm , i.e. moda⊆ dm .
The process is as follows:
a) Verify that attn=…Σ ,,tagt,,()ag ,tag is a valid attestation on m under the verification key
()
msgn1
vk=rk and abort if this is not the case.
b) Set mm′= and atta′= tt .
c) Adjust the admissible changes to no longer contain fields to be redacted, i.e. adm’ = adm \ mod.
d) For all im∈ od :
1) Compute the hash-code ht=Hash ag mtag using the collision-resistant hash-function.
()
imsg ii
2) Replace the content of m with h , i.e. set mm′=(),,……mh,,mm,, .
i i 11ii−+in1
λ
3) Set tag = 0 to indicate that this field has been redacted, i.e. modify the attestation to
i
λ
attn′= Σ ,,tagt,,ag ……,,tagt0 ,,ag ,tag .
()()
msgi11−+in1
The process outputs:
— redacted message m’;
— redacted attestation att’;
— redacted admissible changes adm’ = adm \ mod.
© ISO/IEC 2024 – All rights reserved
6.2.4 Verification process
The process takes the following inputs:
— set of domain parameters Z ;
— verification key vk ;
— redacted or original message mm=…,,m ;
()
1 n
— redacted or redactable attestation attn=…Σ ,,tagt,,()ag ,tag ;
()
msgn1
— original or redacted admissible changes adm .
The process is as follows:
[17]
a) Generate a Merkle tree as follows: generate a balanced binary tree of sufficient height such that it has
k leaf nodes with 2nk>≥n .
λ
b) For each in=…1, , , compute the hash-code ht=Hash ag mtag if tag ≠ 0 using a collision-
()
imsg ii i
λ
resistant hash-function; and if tag = 0 then set h to the value supplied as m as it has been redacted
i i i
previously, which corresponds to the value of Hash tagmtag .
()
msgi i
c) Initialize the Merkle tree using hh,,… as values for the n left-most leaf nodes of the balanced binary
1 n
tree, use the empty string for all remaining kn− leaf nodes.
d) Calculate the value for the root (denoted as root ) of the Merkle tree.
e) Use the digital signature’s verification process on inputs:
— set of domain parameters Z ;
— verification key mapped from the verification vk
— message: root ,,tagn ;
()
msg
— signature: Σ .
Receive from the digital signature’s verification process an output oa∈{}ccept ,reject .
The process outputs:
— The final verification outcome o .
NOTE 1 The redactable attestation scheme specified in 6.2.1 to 6.2.4 satisfies the following properties:
unforgeability, privacy, detectability of redactions and mergeable. See Annex B for further details.
NOTE 2 Security proofs for unforgeability and privacy are found in the Reference [12]. Detectability of redactions
and mergeability are shown in Reference [15]. See Annex B for further details.
[12]
NOTE 3 This scheme was originally introduced by R. Steinfeld, L. Bull, and Y. Zheng in 2001.
7 Scheme SBZ02-MERSAProd
7.1 Parameters
The SBZ02-MERSAProd scheme makes use of the following parameters:
— collision-resistant hash-function Hash as defined in ISO/IEC 10118-1;
— security parameter λ .
© ISO/IEC 2024 – All rights reserved
The security parameter λ shall be met by all involved algorithms for the hash-function and taken into
account during the choice of the domain parameters and keys.
7.2 Construction
7.2.1 Key generation process
The key generation algorithm of the redactable attestation scheme consists of the following two procedures:
a) generate the set of domain parameters Z;
b) generate the attestation key ak and verification key vk and redaction key rk as follows:
1) The verification key vk consists of a unique RSA (Rivest, Shamir, and Adleman) modulus Np=⋅q
generated according to ISO/IEC 9796-2 and a list ee,,… of public exponents which are pairwise
1 l
co-prime and co-prime to ()pq−11⋅−() . Here, l shall be equal to or larger than the number of fields
in the message being attested.
2) The attestation key ak consists of the modulus N and the secret exponents dd,,… such that for all
1 l
−1
il=…1, , it holds that de≡−modulo pq11⋅− .
() ()
ii
3) The verification key also serves as redaction key, such that rk =vk .
The security parameter λ shall be taken into account when choosing above parameters, such that the
indicated security strength is achieved.
NOTE In case the number of exponents is larger than the number of fields in the message, i.e. in the case of n < l,
some of the l exponents are not facilitated.
7.2.2 Redactable attestation process
This process takes the following inputs:
— set of domain parameters Z ;
— attestation key ak consisting of the l secret exponents dd,,… ;
1 l
— a message m consisting of n fields mm,,… in no particular order, such that each field includes a
1 n
unique index number i with 1≤≤il ;
— admissible changes adm represented as two sets containing the unique index number corresponding to
the fields’ index numbers: the first set adm containing the indices of fields that are not admissible to
fix
redaction and the second set adm containing indices of fields admissible to redactions.
red
NOTE 1 Reference [12] does not define in detail how to efficiently encode the admissible changes.
NOTE 2 This algorithm does not directly protect the order of the fields, as the index number i for each field is only
required to map to a specific exponent in the verification key; the order of those exponents is not protected inside the
algorithms presented in this document.
The process Split() to split the message m into fields is generally out of scope of this document. However, the
process Split() shall be defined in such a way that fields can be transformed into the message and vice versa,
-1
in a reproducible way everytime this conversion is necessary, i.e. if Split( m )= mm,,… then Split (
1 s
mm,,… ) = m . The scheme protects the contents of each field, but not their order.
1 s
The process requires the generation of randomness. Refer to ISO/IEC 18031 to generate this securely.
The process is as follows:
a) Generate a random bit string tag of length λ .
CES
© ISO/IEC 2024 – All rights reserved
b) For each in=…1, , , compute a hash-code h from the concatenation of the content of each field m together
i i
with the adm and the tag using the collision-resistant hash-function: ha=Hash()dmtagnim .
CES iCES i
NOTE 3 How to represent numbers as strings for concatenation is outside the scope of this document.
c) Use the function trans to transform the output of the collision-resistant hash-function to numbers that
can be used as input to the forthcoming RSA operation in step d) and e).
NOTE 4 Reference [12] does not define in detail how to encode the output of the hash-function for use with RSA.
NOTE 5 A compatible transform function is the optimal asymmetric encryption padding (OAEP) as
[29]
standardized in PKCS#1 v2.2 and RFC 8017 and in ISO/IEC 18033-2.
d) For each in=…1, , , sign the trans(h ) with a different exponent to obtain a signature per
i
d
i
field: sh=()transm() oduloN.
ii
n
e) Compute Σ as the product of all fields’ signatures s : Σ = sNmodulo
i i
∏
i=1
The process outputs:
— redactable attestation att =()Σ ,,ntag .
CES
7.2.3 Redaction process
This process takes the following inputs:
— set of domain parameters Z ;
— message m composed of n fields denoted as mm,,… such that each field includes a unique index
1 n
number i that corresponds to the indices to the exponents in the verification key;
— attestation att of the form att = ()Σ ,,ntag ;
CES
— redaction key rkcontaining the list ee,,… of public exponents;
1 l
— admissible changes adm ;
— modification instructions mod , which are represented as a set of the unique indices i that
corresponds to the indices of the fields that will be redacted, that are according to the admissible
changes adm , i.e. moda⊆ dm .
red
The process is as follows:
a) Verify that attn=()Σ ,,tag is a valid attestation on m under the verification key vk=rk and abort if
CES
this is not the case.
b) Check that modification instructions mod are a subset or equal to adm .
c) Set m′ to those fields that shall remain, i.e. remove all m if im∈ od .
i
d) Let X be the set of the indices of all fields in m’.
e) Compute for all kX∈ , using the Chinese-Remainder-Theorem (CRT), the coefficients c such that:
k
1) ce≡1modulo and
kk
2) ce≡0modulo for those ik∈…{}11,, −+,,kn1 …, .
ki
f) For each kX∈compute the hash-code ha=Hash()dmtagnkm .
kCES k
© ISO/IEC 2024 – All rights reserved
g) Use the same function trans as during the attestation process [7.2.2, step c)] to transform the output of
the collision-resistant hash-function to numbers that can be used as input to the forthcoming RSA
operation [in step h)]; compute h =trans(h ) for in=…12,, , .
i i
c ce/
k ki
h) For each kX∈compute sh=Σ / modulo N.
k ∏ i
in=…12,, ,
i) Using thes computed in h) for the remaining fields, compute the product Σ′ of all signatures
k
Σ′= sNmodulo .
k
∏
kX∈
The process outputs:
— redacted attestation att’=()Σ ′,,ntag ;
CES
— redacted message m’;
— admissible changes adm .
NOTE 1 The redaction process does not adjust the initially attested number of fields of the message, denoted as n.
NOTE 2 To calculate the coefficients in step e), any algorithm that solves the equations related to the CRT can be used.
NOTE 3 In step c), the indices corresponding to the remaining m do not change and in particular they will still use
i
the same corresponding exponent e .
i
NOTE 4 In step h), the division is a division modulo N, and not over the integers, while the division in the exponent
is an integer division rounded down.
NOTE 5 The redaction process does not support consecutive redactions (i.e. redacting again an already redacted
attestation) due to the current described handling of indices.
7.2.4 Verification process
The process takes the following inputs:
— set of domain parameters Z ;
— verification key vk containing the list ee,,… of public exponents;
1 l
— redacted or original message mm=…(),,m such that each field includes a unique index number i that
1 n
corresponds to the indices of the exponents in the verification key vk;
— redacted or redactable attestation att = Σ ,,ntag ;
()
CES
— admissible changes adm consisting of adm and adm .
fix red
The process is as follows:
a) Let X be the set of the indices of all fields of the message m .
b) Check if the indices from X are corresponding to the adm by:
1) checking if adm is a subset of or equal to the set X, and
fix
2) checking if the set X is a subset of or equal to the union of adm and adm .
fix red
If any check fails the verification outcome is invalid, i.e. set or= eject and abort.
c) Recompute the hash-code using the concatenation of the content of each field m together with the adm
i
and the tag using the collision-resistant hash-function:ha=Hash()dmtagnim .
CES iCES i
d) Use the same function trans as during the attestation process to transform the output of the collision-
resistant hash-function to numbers capable as input to the RSA operation [in step f)]; compute h =
i
trans(h ).
i
© ISO/IEC 2024 – All rights reserved
e) Compute ee= .
∏ i
iX∈
e
e
i
f) Compute rh= moduloN .
∏ i
iX∈
e
g) If r = Σ then set
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...