美文网首页平时生活和工作中的iOSiOS 程序员iOS之网络
iOS RSA的网络安全模型、iOS签名机制总结(登录、toke

iOS RSA的网络安全模型、iOS签名机制总结(登录、toke

作者: Peak_One | 来源:发表于2016-03-20 12:41 被阅读9656次
    摘要

    最近公司准备做一个安全级别比较高的项目:技术总监给我们提出了一个这样子的需求:在http请求过程中,即使嗅探器捕获到网络请求的链接也无法去请求到数据。经过一番思考,觉得支付宝的签名完全符合这样子的需求。但是之前自己对签名、RSA等知识也是知道的很少,所以花了一番功夫学习了一下。本文将针对RSA登录和http请求作讲解,希望对大家有所帮助。

    一.登录、登录保持(http请求)

    登录机制

    登录机制大概可以分为一下三个阶段:
    1. 登录验证:是指客户端提供用户名和密码,向服务器提出登录请求,服务器判断客户端是否可以登录并向客户端确认。
    2. 登录保持:是指客户端登录后, 服务器能够分辨出已登录的客户端,并为其持续提供登录权限的服务器。
    3. 登出:是指客户端主动退出登录状态。

    第一种网络请求情况(安全级别:II)

    一般的情况是这个样子的:一但用户登陆成功(单方面MD5加密:服务器加密则客户端不加密,客户端加密则明文传输),服务器为客户端分配sessionID(也可以称为userID),当然有些服务器不但为客户端分配了userID还有可能会为用户提供token了(这个下面会做解释),然后每次网络请求都将sessionID当做参数传递给服务器。

    优点

    能够保持用户登录状态、区分用户,相对于不返回任何信息的登录要安全了一些。

    缺点

    如果通过网络嗅探器(例如:青花瓷)可以获取到http链接,这样子服务器返回的sessionID便会被获取到,这样子依然会造成信息泄露,并且还能被伪造请求(浏览器请求)。

    第二种网络请求情况 (安全级别:III)

    第一种存在明显的安全隐患,但是目前市面上的好多app依然采用第一种方法去实现登录、网络请求,但是对于安全级别较高的app,已经不再适用了。所以在此基础上进行优化----采用非对称加密(公钥、私钥)。

    登录模型

    客户端第一次发出登录请求时, 用户密码以明文的方式传输, 一旦被截获, 后果严重。因此密码需要加密,例如可采用RSA非对称加密。具体流程如下:

    1. 客户端向服务器第一次发起登录请求(不传输用户名和密码)。
    2. 服务器利用RSA算法产生一对公钥和私钥。并保留私钥, 将公钥发送给客户端。
    3. 客户端收到公钥后, 加密用户密码, 向服务器发起第二次登录请求(传输用户名和加密后的密码)。
    4. 服务器利用保留的私钥对密文进行解密,得到真正的密码。
    第三种网络请求情况(安全级别:IIII)

    再仔细核对上述登录流程, 我们发现服务器判断用户是否登录, 完全依赖于sessionId, 一旦其被截获, 黑客就能够模拟出用户的请求。于是我们需要引入token的概念: 用户登录成功后, 服务器不但为其分配了sessionId, 还分配了token, token是维持登录状态的关键秘密数据。在服务器向客户端发送的token数据,也需要加密。于是一次登录的细节再次扩展。

    • 客户端向服务器第一次发起登录请求(不传输用户名和密码)。
      服务器利用RSA算法产生一对公钥和私钥。并保留私钥, 将公钥发送给客户端。
    • 客户端收到公钥后, 加密用户密码,向服务器发送用户名和加密后的用户密码; 同时另外产生一对公钥和私钥,自己保留私钥, 向服务器发送公钥; 于是第二次登录请求传输了用户名和加密后的密码以及客户端生成的公钥。
    • 服务器利用保留的私钥对密文进行解密,得到真正的密码。 经过判断, 确定用户可以登录后,生成sessionId和token, 同时利用客户端发送的公钥,对token进行加密。最后将sessionId和加密后的token返还给客户端。
    • 客户端利用自己生成的私钥对token密文解密, 得到真正的token。
      图示如下:


      login-300x181.png
    登录保持(也就是http数据请求阶段)

    引入token后,http请求被获取问题便可得到解决。 服务器将token和其它的一些变量, 利用散列加密算法得到签名后,连同sessionId一并发送给服务器; 服务器取出保存于服务器端的token,利用相同的法则生成校验签名, 如果客户端签名与服务器的校验签名一致, 就认为请求来自登录的客户端。(支付宝一样的机制)
    结构图如下:


    keep_login.png

    注:token失效的两种情况:
    1. 用户登录出系统
    2. token在后台的规定时间内失效(每个token都是有时间效应的)

    失效原理:
    

    在服务器端的redis中删除相应key为session的键值对。

    二.散列算法

    散列是信息的提炼,通常其长度要比信息小得多,且为一个固定长度。加密性强的散列一定是不可逆的,这就意味着通过散列结果,无法推出任何部分的原始信息。任何输入信息的变化,哪怕仅一位,都将导致散列结果的明显变化,这称之为雪崩效应。散列还应该是防冲突的,即找不出具有相同散列结果的两条信息。具有这些特性的散列结果就可以用于验证信息是否被修改。

    散列算法可以用来加密token生成签名, 以便token信息不暴露在网络同时还能验证登录的有效性。

    MD5

    全写: Message Digest Algorithm MD5(中文名为消息摘要算法第五版)
    输出: 128bit

    MD5算法具有以下特点:

    1、压缩性:任意长度的数据,算出的MD5值长度都是固定的。
    2、容易计算:从原数据计算出MD5值很容易。
    3、抗修改性:对原数据进行任何改动,哪怕只修改1个字节,所得到的MD5值都有很大区别。
    4、弱抗碰撞:已知原数据和其MD5值,想找到一个具有相同MD5值的数据(即伪造数据)是非常困难的。
    5、强抗碰撞:想找到两个不同的数据,使它们具有相同的MD5值,是非常困难的。
    缺陷:Md5一度被认为十分靠谱。2004年8月17日的美国加州圣巴巴拉的国际密码学会议(Crypto’2004)上,来自中国山东大学的王小云教授做了破译MD5、HAVAL-128、 MD4和RIPEMD算法的报告,公布了MD系列算法的破解结果。2009年,冯登国、谢涛二人利用差分攻击,将MD5的碰撞算法复杂度从王小云的242进一步降低到221,极端情况下甚至可以降低至210。仅仅221的复杂度意味着即便是在2008年的计算机上,也只要几秒便可以找到一对碰撞。Md5已老, 在安全性要求较高的场合,不建议使用。

    SHA1

    全名: 安全哈希算法(Secure Hash Algorithm)输出: 160bit
    与Md5比较
    相同点:因为二者均由MD4导出,SHA-1和MD5彼此很相似。相应的,他们的强度和其他特性也是相似。不同点:1. 对强行攻击的安全性:最显著和最重要的区别是SHA-1摘要比MD5摘要长32 位。使用强行技术,产生任何一个报文使其摘要等于给定报摘要的难度对MD5是2128数量级的操作,而对SHA-1则是2160数量级的操作。这样,SHA-1对强行攻击有更大的强度。2. 对密码分析的安全性:由于MD5的设计,易受密码分析的攻击,SHA-1显得不易受这样的攻击。3. 速度:在相同的硬件上,SHA-1的运行速度比MD5慢。

    加盐

    所谓加盐, 就是在原本需要加密的信息基础上,糅入其它内容salt。签名的生成就是一次加盐。

    对称加密

    本系统使用对称加密对用户密码进行加密以及生成token字符串。
    AuthCode加密
    AuthCode是康盛科技发明的加密方式, 开源产品Discuz的密码是用这个算法进行加密。但是有点遗憾,这个函数所有权属于康盛创想,并不能自由使用的。不知使用是否有风险??
    AES加密
    高级加密标准(英语:Advanced Encryption Standard,缩写:AES),在密码学中又称Rijndael加密法,是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES,已经被多方分析且广为全世界所使用。

    非对称加密

    RSA是目前最有影响力的公钥加密算法,它能够抵抗到目前为止已知的绝大多数密码攻击,已被ISO推荐为公钥数据加密标准。RSA的安全基于大数分解的难度。其公钥和私钥是一对大素数(100到200位十进制数或更大)的函数。从一个公钥和密文恢复出明文的难度,等价于分解两个大素数之积(这是公认的数学难题)。
    算法描述:
    (1)选择一对不同的、足够大的素数p,q。
    (2)计算n=pq。
    (3)计算f(n)=(p-1)(q-1),同时对p, q严加保密,不让任何人知道。
    (4)找一个与f(n)互质的数e(公钥指数),且1<e<f(n)。
    (5)计算d(私钥指数),使得de≡1 mod f(n)。这个公式也可以表达为d ≡e-1 mod f(n)注,≡是数论中表示同余的符号。
    (6)公钥KU=(e,n),私钥KR=(d,n)。
    (7)加密时,先将明文变换成0至n-1的一个整数M。若明文较长,可先分割成适当的组,然后再进行交换。设密文为C,则加密过程为:


    (8)解密过程为:
    转自:http://blog.csdn.net/m372897500/article/details/50905017 略作了补充

    相关文章

      网友评论

      • WiseDarren:有一个问题就是在获取token之后,是不是应该对请求的数据用token对称加密,然后对加密后的数据签名,将sessionId+加密数据+签名值一起放在请求里面,这样即使别人拦截了也获取不到我们请求的参数吧,像你说的sessionId+签名+资源请求,如果不对请求的参数什么的加密,别人拦截了之后不大好,希望跟你好好讨论一下!
        Peak_One:@MyDarren 可以对请求数据进行再次加密,这一块你可以采用一些简单的加密方式就够了
      • charlotte2018:我想问下,我们就是客户端放一个公钥,一个私钥,公钥用来加密发送给服务器得数据,私钥用来解密服务器传来的数据,现在有个问题,如果有人把我客户端反编译了,把我的私钥取出来了,人家就知道服务器给我返回的数据了吧
        Peak_One:@charlotte2018 选取一些不可逆向的算法,再加一次密,就OK了
      • bdd22d5bf2e0:博主能否发个demo给我,不感感激 451878321@qq.com
      • 从此你不再颠沛流离:服务器将token和其它的一些变量, 利用散列加密算法得到签名后,连同sessionId一并发送给服务器,

        这里的服务器应该是客户端吧
        其实狠爱你:应该是作者打错了
      • smkoc:写了好复杂
      • 谢谢生活:写的非常好,
      • MichaelHuyp:也就是按作者的说法客户端获取到了token之后每次请求都会在请求头中放上这个token 如果token被黑客拦截了就不好了 应该用服务器发给客户端的公钥对token进行加密。然后再发送网络请求。服务器拿到加密后的token对token进行私钥解密 对比。 这样更安全。是吧作者
        Peak_One:@MichaelHuyp token生成的时候可以根据这个去生成
        MichaelHuyp:@Peak_One 又想了一下token中应该加入设备的唯一标识。
        Peak_One:@MichaelHuyp 是的
      • MichaelHuyp:我觉得最后一次获取到token之后还要对token进行一次RSA加密传给服务器
      • ___as7:大赞.. :heart_eyes:
      • 丶雨凡:网上的教程看的实在是云里雾里:sob:
      • 丶雨凡:你好,你能告诉我怎么在手机端生成RSA密钥对不?
      • 润泽笔下:https 是不是就搞定了 ,信息被拦截,篡改的问题了
        Peak_One:@E代斗士 嗯嗯
      • rolei:网络传输中,服务器和客户端 传送 私钥与公钥。这样公钥和私钥被窃取了,黑客是不是可以模拟用户发送信息请求呢?
        Peak_One:@rolei 不一定,看你的加密算法了
      • woshishui1243:也就是说token只是作为用户已登录的标识,sessionID是作为用户信息的标识?那这样我觉得这两个标识符本身可以合二为一啊
        Peak_One:@woshishui1243 你说的这种可以合二为一,但是很多情况下都会习惯性的带上Id,这样服务器那边就不需要再通过token去计算了
        woshishui1243:用服务器返回的公钥和客服端产生的私钥进行加密,这样并不会暴露出来啊
        Peak_One:可以呀,但是token是不能暴露出去的
      • woshishui1243:客服端获取到sessionID后,通过客服端产生的私钥2和服务端产生的公钥1对sessionID进行加密,这样不是也可以保证安全吗?为何要产生一个token?当用户退出后台一定时间或者用户退出后,清除客服端保存的sessionID不就可以做到吗?
        woshishui1243:@Peak_One 在线等,求解答
        woshishui1243:@Peak_One 有了sessionID不就可以说明用户已登录吗?
        Peak_One:@woshishui1243 token是为了说明用户已登陆
      • tjfeng88:既然想办法对token做加密,为何不直接对session作加密处理?岂不更简单?因为"服务器不但为其分配了sessionId, 还分配了token, token是维持登录状态的关键秘密数据"的原因?还有一点不明白就是密码客户端加密,服务器端解密比对,服务器端岂不是知道密码的明文,如果对安全要求很严格的话,服务器最好还是不要知道密码明文的好,不知我理解错了没?求大神指教!
        雨影:你说的这种情况这样是为了防止企业后台密码库泄露的考虑,防止黑客拿着明文密码库去撞库,这里完全可以采用加密保存密文的形式避免.这里说的是为了防止传输过程中被截获从而假冒用户做坏事用的.
        可能有的企业就想知道用户原来的密码,用于大数据收集什么的
        tjfeng88:@Peak_One 对 只需比对比如通过摘要算法(MD5/SHA)处理过的字符串即可,谢谢你的神速回复
        Peak_One:@BossKing10086 可以不给服务器传明文,这个你可以把传给服务器的密码用不可逆的加密方式传给服务器也可以
      • 0a2c3bbff371:作者我想问问怎么在客户端生成RSA密钥对呢?可以把代码给贴出来么
        Peak_One:@0a2c3bbff371 其实还有一种,这样子手机端就不需要去生成RSA密钥对了,就是通过服务器返回的公钥,仅仅只通过服务器返回的公钥进行签名就可以了
        0a2c3bbff371:@Peak_One 受教了,找到解决的方法了,谢谢作者了
        Peak_One:@0a2c3bbff371 配置OpenSSl,这个网上很多的
      • newbiecoder:学习了 谢谢!

      本文标题:iOS RSA的网络安全模型、iOS签名机制总结(登录、toke

      本文链接:https://www.haomeiwen.com/subject/ntzhlttx.html