openssl3.2 - exp - 用openssl命令行来模拟ECC加解密的全流程

文章目录

- openssl3.2 - exp - 用openssl命令行来模拟ECC加解密的全流程
- 概述
- 笔记
- 实验环境
- 实验
- 备注
- END

openssl3.2 - exp - 用openssl命令行来模拟ECC加解密的全流程

概述

工程中要用到ECC加解密, 先去查了资料.
在网上能查到一些大佬们写的ECC加解密实现(基于openssl API), 不过写的都比较早. 仅仅作为参考.

openssl API并不向下兼容, 只要换了openssl版本, 大概率程序得改(改多该少的问题).
从网上找到的第三方代码, 大概率不能用(API的名字都不同). 而且网上能查到的实现, 都不说自己用的openssl具体版本.
如果要找到和自己openssl版本一致, 拿来就能用的代码, 只能看自己版本的openssl实现(包括apps/demo/openssl内部实现中调用的openssl API)

我是准备从openssl实现中移植(抄代码), 这个方法靠谱, 只要能找到代码, 都是官方原装实现(权威用法).
先用openssl命令行模拟了一次.
后续准备将openssl命令行实现单步调试一下, 将openssl API调用代码迁移到自己工程.

笔记

实验环境

win10x64最新版 + openssl3.2

实验

打开自己做的的openssl命令批处理(PATH变量包含了openssl/bin路径, 可以直接运行openssl命令)

进入实验目录

cd /d D:\my_dev\my_local_git_prj\study\openSSL\exp\exp019_ecc_enc_dec

建立2个用户

mkdir .\sender && mkdir .\receiver

sender/receiver两端必须采用相同的椭圆曲线, 否则ECC共享密钥推导不出来

切换到sender

cd .\sender

产生ecc私钥_sender

openssl ecparam -name sect571r1 -genkey -noout -out priv_key_s.pem

导出ecc公钥_sender 给receiver

openssl ec -in priv_key_s.pem -pubout -out ..\receiver\pub_key_s.pem

切换到receiver

cd ..\receiver

产生ecc私钥_receiver

openssl ecparam -name sect571r1 -genkey -noout -out priv_key_r.pem

导出ecc公钥_receiver 给sender

openssl ec -in priv_key_r.pem -pubout -out ..\sender\pub_key_r.pem

双方各自在自己的一边(物理隔离)单独推导出共享密钥

sender单独推导出共享密钥

cd ..\senderopenssl pkeyutl -derive -inkey priv_key_s.pem -peerkey pub_key_r.pem -out shared_key_s.sk

receiver单独推导出共享密钥

cd ..\receiver
openssl pkeyutl -derive -inkey priv_key_r.pem -peerkey pub_key_s.pem -out shared_key_r.sk

确认双方共享密钥是一把

fc /B .\shared_key_r.sk ..\sender\shared_key_s.sk

可以看到双方推导出的共享密钥是一把.

看了资料, 当双方各自独自推导出共享密钥后, 密钥交换就完成了.
下面就是拿共享密钥去对称加解密. 直到本次通讯结束.
当新的通讯开始时, 为了保证前向安全性, 还需要进行新的ECDH, 用来保证每次通讯的共享密钥不一样

sender准备明文

cd ..\sender
echo msg from sender > pt.txt

制作会话密钥(每次会话都做新的会话密钥, AES256的密钥为32个字节)

openssl rand -hex 32 > session_key.sek 2>&1

查看会话密钥值, 后面对称加密时要用, 必须在命令行直接输入, 指定文件不好使.

more session_key.sek

e90b95cbcfa054d6ec2e8e2f3725254fd26096e8d50ee69550a14db32cffaa96

sender加密会话密钥

~~openssl enc -k file:shared_key_s.sk -e -in session_key.sek -out session_key.sek.enc~~

单步调试了, 上面这个命令并不能加密会话密钥, 只是将会话密钥原样输出到session_key.sek.enc.
原因是没有指定加密算法.
但是这里要用指定的EC算法, 而不是对称加密.
@todo 在研究这块.

双方生成自己的ECC私钥/公钥, 然后将自己的公钥给对方, 然后双方从自己的私钥和对方公钥推导出共享密钥, 这是ECDH(ECC的密钥交换算法), 需要每次通讯都生成新的ECC密钥对才安全, 保证了通讯的前向安全性.

对于离线应用, 一次ECDH过程相当于发放一次授权文件. 来保证授权文件的共享密钥每次都不同(前向安全性).
服务端对参数文件对称加密用的密钥为(ECC共享密钥加密客户端指纹, 然后做摘要为适合对称加密算法长度的MD), 用这个MD去加密客户端应用要用到的参数文件. 这样安全. 可以保证用客户端指纹来控制客户端的模块功能数量.

ECDH保证的是通讯过程中的密钥安全交换.
不过说到底, 离线应用和在线应用(TLS)还是不一样的, 离线应用如果被用户逆向的改掉(使用正版用户才能看到的参数), 甩掉参数文件, 还是防不住的. 最终还是防不住正版用户.

防止用户在客户端来改程序的2进制内容, 那是另外的思路了.

sender产生IV(AES对称加密要用, iv长度为16个字节)

openssl rand -hex 16 > session_iv.sek

查看IV值, 加密是要用

more session_iv.sek
0ffcf7d0b32a813ddc3ff63fdfb02b73
这个iv值用命令行AES加密时, 要在命令行直接输入, 指定文件不好使.

sender用会话密钥对称加密明文, 对称加密算法为aes-256-cbc(如果编程来加密, 可以选择更好的aes-256-gcm)

openssl enc -aes-256-cbc -K e90b95cbcfa054d6ec2e8e2f3725254fd26096e8d50ee69550a14db32cffaa96 -iv 0ffcf7d0b32a813ddc3ff63fdfb02b73 -e -in pt.txt -out pt.txt.enc

现在将session_key.sek.enc, session_iv.sek, pt.txt.enc 一次发给对方(其中iv不是机密数据, 直接给就行. 实际应用中, 这些数据合成一个大buffer, 直接甩给对方)

copy .\session_key.sek.enc ..\receiver\session_key.sek.enc
copy .\session_iv.sek ..\receiver\session_iv.sek
copy .\pt.txt.enc ..\receiver\pt.txt.enc

recevier操作

cd ..\receiver

从加密的会话密钥session_key.sek.enc中解密出会话密钥

openssl enc -k file:shared_key_r.sk -d -in session_key.sek.enc -out session_key.sek.enc.dec

确认解密的会话密钥和原始的会话密钥相同

fc .\session_key.sek.enc.dec ..\sender\session_key.sek

确认了现在解密出的会话密钥和加密时的会话密钥相同.

查看解密后的会话密钥

more .\session_key.sek.enc.dec
e90b95cbcfa054d6ec2e8e2f3725254fd26096e8d50ee69550a14db32cffaa96

查看发送者给的iv

more .\session_iv.sek
0ffcf7d0b32a813ddc3ff63fdfb02b73

用会话密钥解密明文

openssl enc -aes-256-cbc -K e90b95cbcfa054d6ec2e8e2f3725254fd26096e8d50ee69550a14db32cffaa96 -iv 0ffcf7d0b32a813ddc3ff63fdfb02b73 -d -in pt.txt.enc -out pt.txt.enc.dec

确认解密后的明文是否为原始明文