アカウント名:
パスワード:
エンドツーエンドで暗号化した場合はAppleが復号できなくなってしまう。
エンドツーエンドだから、片方はユーザー、もう片方はicloud側に鍵があるんじゃないの？
ファイル送信サービスで発信者と送信者を同じにした状態と、iCloudのファイル共有を同じと想定すれば、iCloudはエンドではなく中継サーバ
Appleは「iOS端末でバックアップ→iCloudで保管→iOS端末で復元」という一連のプロセスをエンドツーエンドで暗号化 [apple.com]と呼んでいるようですね。私も最初は困惑しました。
>「iOS端末でバックアップ→iCloudで保管→iOS端末で復元」
このプロセスは正しいんだけど、これをエンドツーエンドとは呼んでない。エンドツーエンドはサーバー側でも複合できないことを意味する。AppleのサービスにおいてE2Eなのは、iMessageやKeyChainやヘルスデータなど一部の機密性の高いデータのみ。他はサーバー側でAppleの鍵で暗号化してる。なので、Appleは復号できる。
iCloudバックアップはE2Eの対象にはなってない。計画してたが諦めたというのが今回のネタ。
今は「iOS端末をバックアップ -(経路暗号化)→ iCloudで保管(Appleの鍵で暗号化) -(経路暗号化)→
暗号化についてのエンドツーエンドって、自分の常識だと
自分の端末（自分の鍵で暗号化） -> サーバー(暗号文) -> 自分の他の端末（自分の鍵で復号）
って意味だけど、別の常識があるの？HTTPSもエンドツーエンドと呼んじゃうの？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
e2e (スコア:0)
エンドツーエンドで暗号化した場合はAppleが復号できなくなってしまう。
エンドツーエンドだから、片方はユーザー、もう片方はicloud側に鍵があるんじゃないの？
Re: (スコア:0)
ファイル送信サービスで発信者と送信者を同じにした状態と、
iCloudのファイル共有を同じと想定すれば、iCloudはエンドではなく中継サーバ
Re: (スコア:0)
Appleは「iOS端末でバックアップ→iCloudで保管→iOS端末で復元」という一連のプロセスをエンドツーエンドで暗号化 [apple.com]と呼んでいるようですね。私も最初は困惑しました。
Re: (スコア:0)
>「iOS端末でバックアップ→iCloudで保管→iOS端末で復元」
このプロセスは正しいんだけど、これをエンドツーエンドとは呼んでない。
エンドツーエンドはサーバー側でも複合できないことを意味する。
AppleのサービスにおいてE2Eなのは、iMessageやKeyChainやヘルスデータなど一部の機密性の高いデータのみ。
他はサーバー側でAppleの鍵で暗号化してる。なので、Appleは復号できる。
iCloudバックアップはE2Eの対象にはなってない。計画してたが諦めたというのが今回のネタ。
今は
「iOS端末をバックアップ -(経路暗号化)→ iCloudで保管(Appleの鍵で暗号化) -(経路暗号化)→
Re: (スコア:0)
暗号化についてのエンドツーエンドって、
自分の常識だと
自分の端末（自分の鍵で暗号化） -> サーバー(暗号文) -> 自分の他の端末（自分の鍵で復号）
って意味だけど、別の常識があるの？
HTTPSもエンドツーエンドと呼んじゃうの？