OpenSSL 3.0 简介(2)

        以下概念来自 FIPS 140 标准:
1)POST (Power On Self Test),即“上电自检”;
2)KAT (Known Answer Tests),即“已知答案测试”,是指在输入和对应的输出值已知的情况下,检查一个程序在获得输入固定值后,输出值是否与已知的对比值一致;
3)CSP (Critical Security Parameters),即“关键安全参数”,例如密钥就属于CSP;
4)State Machine,即“状态机”。

        OpenSSL 3.0 版中引入了以下概念:
1)提供者(Provider);
    OpenSSL 3.0 中包含了四个标准的提供者,它们分别是:
    a)默认的内建提供者;它包含当前那些正在被使用的主流密码算法,不包含那些已被证明不安全、被弃用的密码算法。
    b)遗留提供者(Legacy Provider);它为遗留算法(即被废弃的算法)提供访问,以下是关于遗留算法的一个不完整的列表:Blowfish,CAST,DES,DSA,IDEA,MD2,MD4,MDC2,RC2,RC4,RC5,RIPEMD 160,SEED,Whirlpool。注意 3DES 不属于遗留算法。
    c)引擎(Engine);“引擎”的概念在先前的 OpenSSL 版本中就存在,是为调用硬件执行密码运算而设计的。OpenSSL 3.0 中包含一个在为老版本 OpenSSL 设计的引擎和基于新的提供者方法设计的引擎之间的一个兼容层。在未来整个引擎 API 都会被废弃,相关代码也将被移除。到那时将不再使用引擎,而是通过调用与硬件相关的提供者模块来访问硬件。现有的与引擎模块相关的实现代码,都要按照 OpenSSL 3.0 版的新设计思路被转化为调用提供者方式的实现代码。
        在 3.0 版本中重构 OpenSSL 时,支持“提供者”的需求与支持引擎”的需求冲突,冲突涉及原有的 ENGINE API 以及特定的创建或更改“方法”(METHOD)函数,例如 EVP_MD_meth_new,EVP_CIPHER_meth_new, EVP_PKEY_meth_new, RSA_meth_new, EC_KEY_METHOD_new 等函数,这些函数在 OpenSSL 3.0 中已被建议不再使用,因为使用它们可能导致绕过选择提供者,尤其与 OpenSSL 3.0 中的 FIPS 模块冲突。外部引擎的作者和维护者应当重构现有的代码,改为调用提供者的方式。
    d)一个“FIPS提供者”。设计它的目的是为了实现 FIPS 140-3 《密码模块安全要求》中定义的功能,该提供者可以被动态加载。

    FIPS提供者包括以下服务:POST,低级别的实施(提供了密码学原语对应的实现)。POST 包括模块完整性检查和针对算法的 KAT。在调用 FIPS 模块的入口点函数 OSSL_provider_inti( ) 时将执行 POST。
    第三方可以加入额外的提供者,即第三方自行提供一套密码算法实现,应用程序能借助“核心”来访问这些算法实现。
    提供者有以下特点:
    a)提供对指定算法实现的访问;
    b)将算法实现与一个预定义的属性集合关联起来;
    c)支持参数传递;
    d)可以在任意时间点被加载;
    f)包含模块的“入口点”(entry point)。

2)核心(Core)。
    它是 libcrypto 库文件的一个组成部分,应用程序可以通过核心来访问提供者提供的密码算法实现函数。核心是一个基础组件,它将一个操作请求(比如加密)连接到相关的提供者,并提供了定位一个算法实现的能力。也就是说核心提供了一种机制,借助于该机制可以确定具体密码运算实现所在的位置。
    核心有以下特点:
    a)能实现发现、加载、初始化和卸载提供者;
    b)允许实现基于属性的算法查询;
    c)实施了对算法查询和算法实现细节的缓存;
    d)在一个“库上下文”(library context)范围中操作,库上下文包含全局属性数据、搜索缓存和调度表(dispatch table)。

    对于核心与提供者的关系,可以用一个粗略的比方来说明:核心好像是一个工头,管理着好几个工人(工人对应于提供者),工头(核心)了解每个工人(提供者)具备哪些工作能力。当用户(与应用程序相对应)需要做加解密时,先去找工头(核心),工头(核心)查询工人(提供者)的工作能力清单,把加解密任务分配给某一个能够承担该项任务的工人(提供者),具体的加解密工作由工人(提供者)来完成。

3)EVP
    注意 EVP 不是一个新概念,在 OpenSSL 3.0 之前的版本中就包含 EVP。由于历史原因,OpenSSL 为调用密码算法提供了两套API,即 EVP 和低层次 API。EVP 是在 libcrypto 库文件中实施的一族 API,用于执行各种密码运算,EVP API 的实现用到了“核心”和“提供者”这两个组件。EVP 接口可以适用于所有的算法类型,而低层次 API 只能适用于某种特定的算法实现。例如 EVP 接口提供了函数 EVP_EncryptInit_ex, EVP_EncryptUpdate 及 EVP_EncryFinal 来执行对称加密,AES、CHACHA、3DES 等算法相关的加解密都可以通过这些 EVP 函数来实现。对于 AES 密码算法,可以调用特殊的低层次函数 AES_set_encrypt_key、AES_encrypt 等函数来做 AES 加密,这几个函数只适用于 AES 算法,并且未通过 EVP 接口 API 来提供服务,将来会被废弃。EVP API 还封装了一些密码学对象,用于执行相关的服务,此类函数一般以 EVP_PKEY,EVP_CIPHER,EVP_MD 等字符串开头。
    一直以来 OpenSSL 开发团队都不建议用户调用低层次的 API 接口。从 OpenSSL 3.0 版开始,这些低层次的 API 都将逐步被弃用。尽管有一些可能还能被调用到,但用户将看到编译器发出的警告(具体情况与所用的编译器有关)。在未来的 OpenSSL 版本中可能会完全移除它们,所以用户应当升级现有的代码,将以前调用低层次 API 改为调用 EVP API 接口。
    所有通过提供者实现的密码算法都要通过 EVP 接口来调用,而不允许通过低层次的 API 接口来调用。

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值