V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
RqPS6rhmP3Nyn3Tm
V2EX  ›  Apple

关于 iMessage 点对点加密的问题

  •  
  •   RqPS6rhmP3Nyn3Tm · 2016-03-06 22:50:45 +08:00 · 5493 次点击
    这是一个创建于 2977 天前的主题,其中的信息可能已经有所发展或是发生改变。

    个人使用下来,对 iMessage 安全性有一点疑问。虽然可以以很低的成本和周边的人进行加密通信,但是请问如果能进行跨设备的消息同步,意味着私钥并不是 per device ,而是 per Apple ID 。如果苹果在服务器保存了你的私钥,为何说苹果自身也没有能力解密 iMessage 的信息呢?
    希望大神解惑

    15 条回复    2016-03-08 13:40:40 +08:00
    crystom
        1
    crystom  
       2016-03-06 22:58:30 +08:00
    imessage 并不是开源协议,能不能解密只有 apple 知道,就我国的情况看是可以的哦
    RqPS6rhmP3Nyn3Tm
        2
    RqPS6rhmP3Nyn3Tm  
    OP
       2016-03-06 23:06:43 +08:00
    @crystom 呃,我主要想知道上传私钥的问题,后门这种东西除了苹果谁也不知道哇
    ryd994
        3
    ryd994  
       2016-03-07 02:11:32 +08:00   ❤️ 1
    “如果能进行跨设备的消息同步,意味着私钥并不是 per device ,而是 per Apple ID ”
    这个不对
    登录 apple ID -> 上传公钥(私钥硬件储存)-> 发消息的时候对方下载所有公钥
    并不是说就是这么实现,这只是一种可行解
    参考 GPG
    ranye
        4
    ranye  
       2016-03-07 05:29:44 +08:00
    我以前读过的一片分析说私钥是 per device 的, 但是同步时私钥会通过 Apple 服务器传到另一台设备上(估计是使用了 Apple ID 进行了加密), Apple 声称是不保存私钥的。至于安不安全自己评估吧。
    minsheng
        5
    minsheng  
       2016-03-07 06:19:54 +08:00 via iPhone
    是 per device 的,你有几个设备发消息给你的手机就要加密几次,那个安全白皮书说的挺详细的
    zwl2828
        6
    zwl2828  
       2016-03-07 06:49:17 +08:00   ❤️ 1
    "当用户在设备上打开 iMessage 后,设备会生成以下两对密钥供这一服务使用:用于加密的 RSA 1280 位密钥和 NIST P-256 曲线上用于签名的 ECDSA 256 位密钥。两组密钥对的私钥存储在设备的钥匙串中,公钥则与设备的 APNs 地址一起发送至 Apple 的目录服务( IDS ),在目录服务中,公钥会与用户的电话号码或电子邮件地址关联在一起。

    在用户启用其他设备来使用 iMessage 时,它们的加密和签名公钥、 APNs 地址以及所关联的电话号码都会添加至目录服务中。用户还可以添加更多电子邮件地址,这些电子邮件地址会通过发送确认链接进行验证。电话号码通过运营商网络和 SIM 卡进行验证。而且,当有新设备、电话号码或电子邮件地址添加进来时,用户所有已注册的设备都会显示一条警告消息。"

    via 《 iOS 安全保护白皮书( 2015 年 9 月)》
    RqPS6rhmP3Nyn3Tm
        7
    RqPS6rhmP3Nyn3Tm  
    OP
       2016-03-07 07:11:22 +08:00 via Android
    @ryd994
    @ranye
    @minsheng
    @zwl2828
    感谢回复。所以苹果为每个设备都生成了密钥对,使用是用每一个对方的公钥加密一次。我理解得对吗?
    Sequencer
        8
    Sequencer  
       2016-03-07 09:24:00 +08:00
    我还是保持 iMessage 对政府公开的想法...
    几乎是唯一能用的国外公司的信息软件
    只可能是为了"国家安全"卖了信息给国家...
    odirus
        9
    odirus  
       2016-03-07 09:38:24 +08:00
    这样子吧,你给接收方都配个随机密码本本,定期更换,手动加解密。
    queenz
        10
    queenz  
       2016-03-07 09:41:15 +08:00
    http://blog.quarkslab.com/imessage-privacy.html iMessages Privacy ,超长的分析文。中文译文在此 http://justinyangis.me/blog/2013/12/01/imessage-privacy-1/ http://justinyangis.me/blog/2013/12/05/imessage-privacy-2/

    全文最后一句总结摘录在此 “所以,是的,虽然有点对点的加密,但是由于密钥的构造由苹果公司控制,所以他们可以在任何时候更改密钥来查看我们 iMessage 的内容”

    详情请自己看喽
    jamesfjx
        11
    jamesfjx  
       2016-03-07 10:55:16 +08:00 via iPhone
    @Sequencer 据说某些地区是用不了的
    liuyi_beta
        12
    liuyi_beta  
       2016-03-07 11:28:14 +08:00
    关于 iMessage 加密, Apple 说的很清楚了,以下是引用:

    用户通过输入一个地址或姓名来开始一次 iMessage 对话。如果他们输入一个电话号码或电子邮件
    地址,设备就会与 IDS 进行联系,来提取与该地址相关联的所有设备的公钥和 APNs 地址。如果用
    户输入的是一个名字,设备首先会使用用户的“通讯录”应用来收集与该名字相关联的电话号码和
    电子邮件地址,然后再从 IDS 中获取公钥和 APNs 地址。
    对于每个接收者的设备,用户发出的信息都会单独进行加密。接收设备的公共 RSA 加密密钥取自
    IDS 。对于每台接收设备,发送设备将利用自身所生成的随机 128 位密钥并使用 AES 在 CTR 模式
    下对信息进行加密。此信息独有的 AES 密钥采用接收设备上用于加密公钥的 RSA-OAEP (算法)
    进行加密。之后使用 SHA-1 对加密的信息文本和加密的信息密钥进行混编,该哈希值会使用发送
    设备的专用签名密钥通过 ECDSA 签名。针对每部接收设备所生成的每条信息包含加密的信息文本、
    加密的信息密钥和发送者的数码签名。信息然后会分派至 APNs 以进行发送。时间戳和 APNs 路由
    信息等元数据则不加密。与 APNs 的通信使用前向保密 TLS 频道加密。

    具体可参考: https://www.apple.com/cn/business/docs/iOS_Security_Guide.pdf
    yiciyuansky
        13
    yiciyuansky  
       2016-03-07 14:24:42 +08:00
    从技术上是可以看的,所以就看你是否信任;这世界上大多事情都是如此;
    Sting
        14
    Sting  
       2016-03-08 10:41:13 +08:00
    我只想知道 apple 在美国和 fbi 这样撕逼. 但在这里, 会不会一纸文件就自己把门打开了
    nvidiaAMD980X
        15
    nvidiaAMD980X  
       2016-03-08 13:40:39 +08:00 via Android
    @Sting 我很担心 Tim·Cook 在陆国的节操…………
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2446 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 13:27 · PVG 21:27 · LAX 06:27 · JFK 09:27
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.