ISO/IEC 11770-3-2008: 信息安全与非对称技术密钥管理标准

5星 · 超过95%的资源 | 下载需积分: 25 | PDF格式 | 1.32MB | 更新于2024-07-25 | 86 浏览量 | 举报

"ISO/IEC 11770-3:2008是关于信息技术安全技术领域的一个国际标准，特别关注密钥管理中使用非对称技术的机制。这个标准于2008年7月15日发布，旨在提供清晰且实用的指导，以确保信息安全。" 在信息安全领域，密钥管理是一项至关重要的任务，因为它直接影响到数据的加密与解密以及通信的安全性。ISO/IEC 11770-3标准的第三部分专门针对使用非对称技术的密钥管理机制，这些技术包括公钥基础设施（PKI）中的公钥和私钥对，广泛应用于数字签名、密钥交换和身份验证。非对称技术的核心特点是有一对密钥：一个公开，称为公钥，任何人都可以获取；另一个保密，称为私钥，只有拥有者知道。公钥用于加密数据，而私钥用于解密，这使得即使公钥被他人获取，数据仍然能够保持安全，因为没有对应的私钥无法解密。该标准可能涵盖以下内容： 1. **密钥生成**：详细规定了如何生成和分配非对称密钥对，包括确保密钥的随机性和强度，以及防止密钥被预测或复制。 2. **密钥存储与保护**：强调了私钥的安全存储，可能包括硬件安全模块（HSM）、智能卡或密码保险箱等物理安全措施，以及访问控制策略来防止未授权访问。 3. **密钥分发与交换**：描述了安全地分发公钥和私钥的方法，例如通过证书颁发机构（CA）进行公钥认证，以及密钥交换协议，如Diffie-Hellman或IKE协议。 4. **密钥生命周期管理**：涵盖了密钥的创建、分配、使用、更新、撤销和销毁的完整流程，确保密钥在必要时得到正确处理。 5. **密钥备份与恢复**：规定了如何在密钥丢失或损坏时进行恢复，以避免数据丢失。 6. **身份验证与信任**：讨论了如何建立和维护信任链，确保公钥的可信性，并处理证书撤销列表（CRL）和在线证书状态协议（OCSP）。 7. **法律与合规性**：可能包含对法规遵从性的指导，如数据隐私法规和行业标准，以确保密钥管理符合法律要求。此标准对于任何涉及敏感数据传输、需要保护通信隐私或实施强身份验证的组织都具有重要意义。它为非对称密钥管理提供了标准化框架，帮助组织降低风险，提高信息安全水平。由于标准是2008年的版本，使用时可能需要考虑其是否已更新以适应当前的技术环境。

ISO/IEC 11770-3:2008(E)

A key derivation function produces keys that are computationally indistinguishable from randomly generated

keys. The key derivation function takes as input the shared secret and a set of key derivation parameters and

produce an output of the desired length.

In order for the two parties in a key establishment mechanism to agree on a common secret key, the key

derivation function must be agreed upon. The method of coming to such an agreement is outside the scope of

this part of ISO/IEC 11770.

See Annex B for examples of key derivation functions.

7 Cofactor multiplication

This clause applies only to elliptic curve cryptography. The key agreement mechanisms in Clause 10 and the

key transport mechanisms in Clauses 11 and 12 require that the user’s private key or key token be combined

with another entity’s public key or key token. If the other entity’s public key or key token is not valid (i.e. it is

not a point on the elliptic curve, or is not in the subgroup of order n), then performing this operation may result

in some bits of the private key being leaked to an attacker. An example of this attack is the ‘small subgroup

attack’.

In order to prevent the ‘small subgroup attack’ and similar attacks, one option is to validate public keys and

key tokens received from the other party using public key validation. See ISO/IEC 11770-1 for a description of

public key validation.

As an alternative to verifying the order of the public key or key token, a technique called cofactor multiplication

can be used. The values j and l, defined below, are used for cofactor multiplication in Clause 10.

If cofactor multiplication is desired, there are two options:

1) If cofactor multiplication is used, and incompatibility with those not using cofactor multiplication is

desired, then let j = #E / n and l = 1. If this option is chosen, both parties involved must agree to use

this option, otherwise the mechanism will not work.

2) If cofactor multiplication is used, and compatibility with those not using cofactor multiplication is

desired, then let j = #E / n and l = j

-1

mod n.

NOTE The value j

-1

mod n will always exist since n is required to be greater than 4

√

q and therefore

gcd(n,j) = 1.

If cofactor multiplication is not desired, there is one option:

1) If cofactor multiplication is not used, then let j = 1 and l = 1.

Regardless of whether or not cofactor multiplication is used and the type of compatibility that is chosen, if the

shared key (or a component of the shared key) evaluates to the point at infinity (O

), then the user shall

assume that the key agreement has failed.

It should be noted that it is most appropriate to perform these operations (public key validation or cofactor

multiplication) if the other entity’s public key or key token is not authenticated or the user’s public key is long

term. Performing public key validation for long-term keys and cofactor multiplication for ephemeral (short term)

keys may also have performance advantages.

It should also be noted that if the other entity’s public key is authenticated and the cofactor is small, then the

amount of information that can be leaked is limited. Thus, it may not always be desired that these tests be

performed.

ISO/IEC 11770-3:2008(E)

8 Key commitment

Clause 10 describes key agreement mechanisms where the established key is the result of applying a one-

way function of the private key-agreement keys. However, one entity may know the other entity’s public key or

key token prior to choosing their private key. The entity can control the value of s bits in the established key, at

the cost of generating 2

candidate values for their private key-agreement key in the time interval between

discovering the other entity’s public key or key token and choosing their own private key [19].

A way to address this concern (if it is a concern) at the cost of one additional message/pass in the protocol is

through the use of key commitment. Commitment can be done by having the first entity hash the public key or

key token and send the hash-code to the second entity, the second entity replies with his public key or key

token and the first entity replies with his public key or key token, which the second entity can hash and verify

that the result is equal to the hash-code sent earlier.

ISO 22895 defines cryptographic syntax and processing that can be used to implement the key commitment

protocol defined in this part of ISO/IEC 11770. A DigestedData message, with its optional content absent, is

used to send the key commitment hash along with the digest algorithm and any associated parameters. The

same message with its optional content present is used to exchange the keys. The message recipient retains

the first hash and ensures that this value is identical to the hash on the keys in the second message. When

origin authentication of the key commitment is needed, the DigestedData message can be encapsulated in a

SignedData message. These ISO 22895 messages can be represented in a compact binary form or as XML

markup.

9 Key confirmation

Explicit key confirmation is the process of adding additional messages to a key establishment protocol

providing implicit key authentication so that explicit key authentication and entity authentication are provided.

Explicit key confirmation can be added to any method that does not possess it inherently. Key confirmation is

typically provided by exchanging a value that can (in all likelihood) only be calculated correctly if the key

establishment calculations were successful. Key confirmation from entity A to entity B is provided by entity A

calculating a value and sending it to entity B for confirmation by entity B of entity A’s correct calculation. If

mutual key confirmation is desired, then each entity sends a different value to the other.

Key confirmation is often provided by subsequent use of an established key, and if something is wrong then it

is immediately detected. This is called implicit key confirmation. Explicit key confirmation in this case may be

unnecessary. If one entity is not online (for example, in one-pass protocols used in store and forward (email)

scenarios), then it is simply not possible for the other entity to obtain key confirmation. However, sometimes a

key is established yet used only later (if at all), or perhaps the key establishment process may simply not know

if the resulting key will be used immediately or not. In these cases, it is often desirable to use a method of

explicit key confirmation, as it may otherwise be too late to correct an error once detected. Explicit key

confirmation can also be seen as a way of “firming up” some security properties during the key establishment

process and may be warranted if following a process of conservative protocol design.

An example method of providing key confirmation using a MAC is as follows:

Entities A and B first perform one of the key establishment procedures specified in Clauses 10 and 11 of this

part of ISO/IEC 11770. As a result, they expect to share a secret MAC key K

. They then perform the

following procedure.

1) Entity B forms the message M octet string consisting of the message identifier octet 0x02, entity B’s

identifier, entity A’s identifier, the octet string KT

corresponding to entity B’s key token (or omit the

fields if such does not exist), the octet string KT

corresponding to entity A’s key token (or omit the

fields if such does not exist), the octet string P

corresponding to entity B’s public key-establishment

key (or omit the fields if such does not exist), the octet string P

corresponding to entity A’s public

key-establishment key (or omit the fields if such does not exist) and if present optional additional

Text1:

Text1, || P || P || KT || KT ||A || B || 02 M

ABAB

ISO/IEC 11770-3:2008(E)

where 0x02 is the message number.

2) Entity B calculates

)kdf(KK

ABB

Entity B then calculates

(M)MAC

for the message M under the (supposedly) shared secret key K

of an appropriate MAC scheme.

3) Entity B sends the message M and MAC

(M) to entity A.

4) Entity A calculates

)kdf(KK

ABA

and verifies MAC

(M) on the message M.

5) Assuming the MAC verifies, entity A has received key confirmation from entity B (that is, entity A

knows that K

equals K

). If mutual key confirmation is desired, entity A continues the protocol and

forms the message M'. Form the octet string consisting of the message identifier octet 0x03, entity

A’s identifier, entity B’s identifier, the octet string KT

corresponding to entity A’s key token (or omit

the fields if such does not exist), the octet string KT

corresponding to entity B’s key token (or omit

the fields if such does not exist), the octet string P

corresponding to entity A’s public key-

establishment key (or omit the fields if such does not exist), the octet string P

corresponding to

entity B’s public key-establishment key (or omit the fields if such does not exist) and optional

additional octet string Text2:

Text2,|| P || P || KT || KT || B ||A || 03 M'

BABA

where 0x03 is the message number.

6) Entity A calculates

)(M'MAC

under the (supposedly) shared secret K

using an appropriate MAC scheme.

7) Entity A sends M' and MAC

(M') to entity B.

8) Entity B uses K

to verify MAC

(M') on the message M'. Assuming the MAC verifies, entity B has

received key confirmation from entity A (that is, entity B knows that K

equals K

Other methods of key confirmation are possible. If the shared secret is to be used for data confidentiality

(encryption), one entity can send the encryption of some specific plaintext known to the other entity, for

example, a block of all binary zeros or all binary ones. Care should be taken that any subsequent use of the

key is very unlikely to encrypt the same plaintext as was used for key confirmation. Furthermore, the MAC key

should not be reused after key confirmation.

ISO/IEC 11770-3:2008(E)

10 Secret key agreement

Key agreement is the process of establishing a shared secret key between two entities A and B in such a way

that neither of them can predetermine the value of the shared secret key. Key agreement mechanisms may

provide for implicit key authentication; in the context of key establishment, implicit key authentication means

that after the execution of the mechanism only an identified entity can be in possession of the correct shared

secret key.

The key agreement between two entities A and B takes place in a context shared by the two entities. The

context consists of the following objects: a set S, a set H and a function F. The function F shall satisfy the

following requirements:

9) F operates on two inputs, one element h from H and one element g from S, and produces a result y

in S, y = F(h,g).

10) F satisfies the commutativity condition F(h

,F(h

,g)) = F(h

,F(h

,g)).

11) It is computationally intractable to find F(h

,F(h

,g)) from F(h

,g), F(h

,g) and g. This implies that

⋅

,g) is a one-way function.

12) The entities A and B share a common element g in S which may be publicly known.

13) The entities acting on this setting can efficiently compute function values F(h,g) and can efficiently

generate random elements in H.

Depending on the particular key agreement mechanism further conditions may be imposed.

NOTES

1) Examples of a possible function F are given in Annexes C and D.

2) In practical implementations of the key agreement mechanisms the shared secret key should be

subject to further processing. A derived shared secret key should be computed (1) by extracting bits

from the shared secret key K

directly or (2) by passing the shared secret K

and optionally other

nonsecret data through a one-way function and extracting bits from the output.

3) It will in general be necessary to check the received function values F(h,g) for weak values. If such

values are encountered, the protocol shall be aborted. An example known as the Diffie-Hellman key

agreement is given in Annex C.5.

10.1 Key agreement mechanism 1

This key agreement mechanism non-interactively establishes a shared secret key between entities A and B

with mutual implicit key authentication. The following requirements shall be satisfied:

1) Each entity X has a private key agreement key h

in H and a public key agreement key p

= F(h

,g).

2) Each entity has access to an authenticated copy of the public key agreement key of the other entity.

This may be achieved using the mechanisms of Clause 12.

See Figure 1 for a diagram of key agreement mechanism 1.

剩余89页未读，继续阅读

vapor_55

粉丝: 13
资源: 9

ISO/IEC 11770-3-2008: 信息安全与非对称技术密钥管理标准

ISO IEC 27005-2018 信息技术 安全技术 信息安全风险管理--中译本.pdf

信息安全管理办法，秘钥管理办法，漏洞管理办法.zip

密钥安全管理办法 密钥分发管理

ISO密钥管理：《ISO/IEC 11770-3中文版》

ISO密钥管理：《ISO/IEC 11770-1中文版》

ISO-IEC-18033-2.pdf

ISO 11770-1:2010——信息安全技术：密钥管理框架与通用模型

信息安全工具与技术选型：辅助实施ISO_IEC 27001-2022的解决方案

网络游戏-用于在数字网络中更新对称密钥的简化方法.zip

ISO 14443协议详解：信息技术安全的对称加密认证标准

最新资源

ISO IEC 27005-2018 信息技术安全技术信息安全风险管理--中译本.pdf

密钥安全管理办法密钥分发管理