对称加密 和 应用的重签名

对称加密 和 应用的重签名

对称加密

  • 对称加密方式:明文通过密钥加密得到密文。密文通过密钥解密得到明文。

常见算法

  • DES 数据加密标准(用的少,因为强度不够)
  • 3DEC 使用3个密钥,对相同数据执行3次加密,强度增强 出来之后,几乎就灭亡了
  • AES 高级秘密标准

比较

  • 对称加密
    • 加密解密用同一个key
  • 非对称加密
    • 使用公钥和私钥
  • HASH
    • 不是加密算法

对称加密的模式

  • ECB(Electrinic Code Book) 电子密码本模式。每一块数据,独立加密
    • 最基本的加密模式,也就是通常理解的加密,相同的明文将永远加密成相同的密文,无初始向量,容易受到密码本重放攻击,一般情况下很少用
  • CBC(Cipher Block Chaining) 密码分组链接模式 使用一个密钥和一个初始化向量[iv]对数据执行加密
    • 明文被加密前要与前面的密文进行以后运算后再加密,因此只要选择不同的初始化向量,相同的密文加密后会形成不同的密文,这是目前应用最广泛的模式。CBC加密之后的密文是上下文相关的,但是明文的错误不会传递到后续分组,但如果一个分组丢失,后面的分组将全部作废(同步错误)
  • CBC可以有效的保证密文的完整性,如果一个数据块在传递时丢失或改变,后面的数据将无法正常解密

终端练习值 EBC

  • 创建message.txt文件 加密之前文件的内容

    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    
    复制代码
  • 命令 执行加密指令

    openssl enc -des-ecb -K 616263 -nosalt -in message.txt -out msg1.bin
    复制代码
    • -dec 使用des加密
    • -ecb 使用ecb模式
    • -K 616263 秘密是大写的ABC
    • -nosalt 不实用salt,openssl 默认会生成随机的salt
    • -in message.txt 加密的文件
    • -out msg1.bin 加密的输出文件
  • 使用cat查看加密的文件

    WeChat4b5693de7ba78f9d7eca63d7eff0b17d.png

  • 使用xxd查看

    WeChatf033c8043315126b207b0f58b3f3b2a8.png

    • d1f8 0876 7a80 0184 这8个字节的数据是重复的
  • 更改message.txt 文件 将第四行的前面的00改为88

    0000000000000000000
    1111111111111111111
    2222222222222222222
    8800000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    
    复制代码
  • 再次执行加密指令 生成msg2.bin

    openssl enc -des-ecb -K 616263 -nosalt -in message.txt -out msg2.bin
    复制代码
  • 对比两个输出文件 发现只有红色区域不同了

    WeChat4c3b35dafdb6405cdcd8590de2a7f43f.png

终端练习值 CBC

  • 将message.txt文件中的88恢复为00 加密之前文件的内容

    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    
    复制代码
    0000000000000000000
    1111111111111111111
    2222222222222222222
    8800000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    0000000000000000000
    1111111111111111111
    2222222222222222222
    
    复制代码
  • 命令 多了一个初始化向量

    openssl enc -des-cbc -K 616263 -iv 01020304050608 -nosalt -in message.txt -out msg3.txt
    // 修改message.txt文件 00->88 
    openssl enc -des-cbc -K 616263 -iv 01020304050608 -nosalt -in message.txt -out msg4.txt
    复制代码
    • -dec 使用des加密
    • -cbc 使用cbc模式
    • -K 616263 秘密是大写的ABC
    • -iv 01020304050608 初始化向量
    • -nosalt 不实用salt,openssl 默认会生成随机的salt
    • -in message.txt 加密的文件
    • -out msg3.bin 加密的输出文件
    • 执行两次
  • 查看结果 发现红色区域的内容不一样了

    WeChat8fb1e547337279b4de73e947e9299e03.png

PS 现在的加密算法,都和几何图形有关系 几何里面的变量是有规律的,规则的结果是多变的 例如原上的点,可以有无数多个向量,结果就有无数多个。所以几何向量添加到加密算法中,破解的难度就会加大
PS -K 616263 也可以改为 -K ABC ,也可以使用字符串
PS CCCrypt的安全隐患问题 使用系统的加密方法不安全 可以被断点调试
* 参数可以先异或操作,再加密,解密的时候,先解密,再异或获取明文。但是疑惑之间的参数还是可以被调试的。这是最简单的方式。也可以做参数先做加密,再调用系统的加密方法
* 自己封装的方法可以使用混淆 系统的方法没有办法混淆

应用的重签名

iOS的代码签名

  • 代码签名是对可执行文件或脚本进行数字签名。用来确认软件在签名后未被修改或者损毁的措施。和数字签名原理一样,只不过签名的数据是代码而已.

简单的代码签名

  • 在iOS出来之前,以前的主流操作系统(Mac/Windows)软件随便从哪里下载都可以运行,系统安全存在隐患,盗版软件、病毒入侵、静默安装等等。那么苹果希望解决这样的问题,要保证每一个安装到iOS上的App都是经过苹果官方允许的,怎样才能保证?就是代码签名了
  • 如果要实现验证,其实最简单的方式就是通过苹果官方生成的非对称加密的一对公私钥。在iOS的系统内置一个公钥,私钥有苹果后台保存,我们传app到AppStore时,苹果后台用私钥对app数据进行数字签名,iOS系统下载这个app后,用公钥验证这个签名。若签名正确,这个app肯定是由苹果后台认证的,并且没有被修改过,也就达到了苹果的需求:保证安装的每一个App都是经过苹果官方允许的。
  • 如果我们的iOS设备安装的app只是从AppStore这一个入口,这件事就简单了解决了,没有任何复杂的东西,一个数字签名就搞定了。
  • 但是实际上iOS安装App还有其他的渠道。比如对于我们开发者iOSer而言,我们需要在开发app时直接调试真机的。而且苹果还开发了企业内部分发渠道,企业证书签名的app也需要顺利安装
  • 苹果需要开发这些方式安装app,这些需求就无法通过简单的代码签名来办到了

苹果的需求

  • 安装包不需要上传AppStore,可以直接安装到手机上
  • 苹果未来保证系统的安全性,又必须对安装的app有绝对的控制权
    • 经过苹果允许才可以安装
    • 不能被滥用导致非开发app也能安装
  • 未来实现这些需求,iOS签名的复杂度也就开始增加了,苹果这里给出了方案时双层签名

双层签名流程

  • 准备
    • xcode帮助我们在Mac电脑生成一对公钥M私钥M
    • iPhone手机设备中保存了苹果下发的公钥A
    • 苹果服务端保存的私钥A
  • 通过CRS文件申请证书
    *mac电脑使用公钥M + 组织机构信息生成一个CSR文件,传递给苹果服务器
  • 苹果服务器用私钥A加密公钥M,生成一个证书
    • 证书中包含公钥M公钥M的Hash值,这个证书就是der文件,会下发到mac电脑。
    • 这个证书只能手机解密。
    • 这书里面的公钥M私钥M是一对
    • 私钥M就是p12证书 在钥匙串访问中和证书是绑定在一起的
    • 请求回来之后,证书和p12就绑定了
  • 开发者开发的app,会使用私钥M(p12)进行签名,生成一个app的签名
    • machO、签名和证书都会打包的app中
    • mac电脑将app安装到手机上面
  • 手机验证
    • 苹果的公钥A解密证书,得到公钥M

    • 公钥M能够解析app的签名,验证app的签名,验证通过,说明安装是经过苹果官方允许的

    WeChatcb5e776df0547257a434681e352ba290.png

PS p12可以到处给其他的开发人员 其他的开发人员可以签名app安装到手机设备
PS app的签名是对macho的hash值加密

这就存在一个问题,申请了一个证书,任何设备都可以安装。就不要上传AppStore了。所以苹果限制证书安装的设备数量,限制了期限

  • 限制文件就是权限文件,后面就变成profile文件

    WeChat129fbbc201d112449a00fd93abb2c1d4.png

  • app里面安装的就是描述文件

    WeChat842460a857da5c41e698599c1c9031a5.png

  • profile也是经过签名的,修改任何东西都没用了

    WeChat5ba8e0b0cb7ea273f3407b9b6694f677.png

  • machO文件的签名信息

    WeChat89fb8e126aece5f82794e39cd9ed1eef.png

总结

  • 对称加密
    • AES DES 3DES
    • EBC CBC
    • iv向量8字节
  • 应用签名原理
    • 个人的公钥M 私钥M 官方的公钥A和私钥A
    • 描述文件
© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享