网络数据安全之加密算法的应用

2022-04-05 本文已影响0人 J扣歪

分享内容来源

算法简介

非对称加密（如：RSA）

公钥加密数据用私钥解密
私钥加密数据用公钥解密
密钥不需要传递
数学运算效率低，适合加密小字符串

对称加密（如：AES）

加密和解密的密钥是相同的
效率高

苹果的钥匙串访问

HSAH

算法是公开的
相同数据运算得到的结果是一样的
不同的数据运算，如MD5的导的结果是32个字符串长度的字符串
为什么是32位：MD5运算后得到的是128位的二进制字符串，32位是二进制的十六进制表现形式
散列碰撞：极小概率发生重合
无法逆运算
如指纹识别技术

只能加密不能解密，严格意义上不算加密

加密算法应用-注册/登录

方式

直接将密码明文，传递给服务端。

密码容易被拦截窃取（×）

将密码通过密钥加密，传递给服务端。

密钥及数据一旦泄露，用户的密码也将随之被泄露（×）

将密码通过HASH运算之后，传递给服务端。

即使数据被泄露，被窃取的是hash之后的字符串，且不可逆，用户的明文密码也不会被泄露（√）

规则：客户端及服务不能保存用户明文密码

如何使用HASH算法进行一次安全的注册登录

注册时客户端将用户的密码进行hash运算传递给服务端进行保存，登录时再以同样的的方式传递给服务端由服务端进行验证。

截屏2022-04-02 下午3.44.15.png

思考：由于相同数据对应的hash运算结果是一样的且不可逆，如果以hash运算结果为key去保存对应的数据，那么我们也可能通过hash运算结果得到原始数据
如：CMD5就保存了一些hash数据

加盐
客户端先将一个字符串（盐）拼接到用户的明文密码中再进行hash运算传递给服务端。如用户明文密码是12345后面拼接@##￥%得到12345@##￥%再进行md5加密后得到54efcc63b50c2cd13fcb65f857de7d65再将hash运算后的结果当做密码传递给服务端。

思考：但是需要保证Android、iOS、web等客户端的盐是一致的且保存在了客户端，存在一些将盐泄漏的隐患，且盐不能更换。

HMAC
以oc代码为例，通过传入一个key对数据进行加密得到一个hash运算结果

  /**
     *  计算HMAC MD5散列结果
     *
     *  终端测试命令：
     *  @code
     *  echo -n "string" | openssl dgst -md5 -hmac "key"
     *  @endcode
     *
     *  @return 32个字符的HMAC MD5散列字符串
     */
- (NSString *)hmacMD5StringWithKey:(NSString *)key {
    const char *keyData = key.UTF8String;
    const char *strData = self.UTF8String;
    uint8_t buffer[CC_MD5_DIGEST_LENGTH];
    
    CCHmac(kCCHmacAlgMD5, keyData, strlen(keyData), strData, strlen(strData), buffer);
    
    return [self stringFromBytes:buffer length:CC_MD5_DIGEST_LENGTH];
}

- (NSString *)hmacSHA1StringWithKey:(NSString *)key;
- (NSString *)hmacSHA256StringWithKey:(NSString *)key;
- (NSString *)hmacSHA512StringWithKey:(NSString *)key;

由服务端生成key，发送给客户端，客户端再通过key对密码进行加密发送给服务端，即使key被泄露服务端也可以通过更换key进行补救。

截屏2022-04-02 下午5.28.16.png

衍生业务

服务端可以通过定时更换key来保证安全性（如某些网站过段时间会让用户再次登录）
设备认证：客户端可以通过查看本地是否保存key，来判断当前设备是否是可信任的设备，如果不是需要用户手动认证。只有认证设备服务端才会将key发送给客户端。（iOS端可以将key保存到钥匙串中）

思考：前面的加密流程看似很安全了，但是如果黑客通过WiFi等工具窃取了客户端发送给服务端的加密密码，再通过加密密码直接模拟一次用户登录，那么我们前面无论做了什么方式的加密也将无济于事。

我们也可以制定自己的规则，如：对key进行rsa加密

时间戳

客户端在登录时将（HMAC密码+当前时间戳）进行一次hash运算生成密码，再发送给服务端。
由于在注册时服务端已经保存了用户的HMAC密码，服务端再以同样的方式对HMAC密码进行加密，再将结果与客户端发送过来的密码进行对比。
如果不一致，服务端可将时间戳向前调一分钟再进行加密对比。

截屏2022-04-02 下午5.43.41.png

这样及时被黑客窃取到了加密密码，也是当时时间戳下的密码，最多1分59秒后，这个加密密码也将失效，除非黑客能在1分59秒内窃取到密码，并且向前调一分钟的规则是由服务端决定的，服务端也可将时长调更短。

时间戳是由用服务端发送给客户端，防止客户端本地时间被更改

加密算法应用-拓展

AES+RSA

如果直接用对称加密对数据进行加密，客户端和服务端需要统一密钥并保存到本地，由于加密和解密的密钥是相同的一旦一端被泄露数据将存在隐患。
如果直接通过网络发送密钥，依然存在被截获的风险。
如果使用RSA对数据进行加密，由于数据量庞大效率将会降低。
由于密钥只是一个简单的数据，所以可以使用RSA对AES的密钥进行加密，然后传输。

截屏2022-04-02 下午6.36.56.png

和https的网络安全协议类似

RSA+HASH（数字签名）

如：客户端生成了一个订单信息要发送给服务端进行验证和扣款。

截屏2022-04-05 下午12.39.08.png

客户端将订单信息通过hash算法进行加密，然后又将得到的hash值通过rsa进行加密，最后连同原始数据一起发送给服务端。
服务端收到订单信息后，为了验证订单信息是否被篡改，先将加密后的数据通过rsa进行解密得到hash值，同时将原始数据用客户端同样的hash算法进行加密，再将得到的hash值与解密后的hash值进行比较，如果相等则订单数据未被篡改。
订单数据属于庞大数据不能直接使用rsa。
由于hash算法是公开的，如果只用hash加密，被黑客拦截到数据后黑客也可能会将篡改后的订单信息使用同样的hash算法进行加密。

引申

逆向：有时客户端的原始数据是可以通过逆向汇编等操作调试出来的