E2E暗号化とは何か — ノートをクラウドに預ける前に知っておくこと

iPhone の「設定」を開くと、iCloud のデータ保護には「標準のデータ保護」と「高度なデータ保護」という2つの状態があります。どちらも「暗号化されている」ことに変わりはありません。ところが Apple の説明を読むと、標準の保護におけるメモなどのカテゴリでは暗号化キーが Apple のデータセンターに保管され、パスワードを忘れたあとのデータ復旧などの場面ではユーザに代わって Apple がデータを復号できるのに対し、高度なデータ保護では暗号化キーにアクセスできるのはユーザ本人の信頼できるデバイスだけになります(iCloud のデータセキュリティの概要)。同じ「暗号化」という一語が、事業者に中身が読めるかどうかという正反対の状態を指しているわけです。

日記、健康の記録、仕事の愚痴、パスワードのヒント。ノートには人生で最も私的な文章が集まります。それをクラウド同期するとき、サービスの説明文にある「暗号化されています」の一文からは、あなたのノートを事業者が読めるのかどうかすら分かりません。暗号化には守る範囲の異なる複数の層があり、「どこで暗号化され、鍵を誰が持つか」で意味がまったく違うからです。以下では、その層を3つに分けて仕組みを整理し、説明文の一文からどの層なのかを見分ける方法、そして E2E を選んだときに利用者が引き受ける仕事までを順に見ていきます。

先に全体の見取り図を渡しておきます。暗号化には大きく3つの層があります。運んでいる間だけ守る「通信の暗号化」、置いてある間守るが鍵は事業者が持つ「保存の暗号化」、そして鍵を利用者の端末にしか置かない「エンドツーエンド暗号化(E2E)」。これらは併用される保護です。E2Eは事業者による内容の読み取りを防ぐ設計ですが、端末の保護や復旧も合わせて考えます。

層1: 通信の暗号化 — 運んでいる間だけ守る

ほとんどのサービスは通信を暗号化しています。ブラウザのアドレス欄に鍵マークが出る HTTPS がそれで、あなたの端末とサーバの間を流れるデータを、途中の誰にも読めない形にします。カフェの Wi-Fi で盗み見しようとする人や、経路上の機器を覗ける立場の人に対しては、これで守られます。HTTPS の中身である TLS の仕様書自身も、その目的を「盗聴、改ざん、メッセージの偽造を防ぐように設計された通信」と定義しており、守る対象が通信路であることが明確です(RFC 8446)。

ただし、通信の暗号化が守るのは「運んでいる間」だけです。TLSによる通信の暗号化はサーバ側で終わります。ただし、その中のデータが別途暗号化されていれば、内容まで平文になるわけではありません。つまり通信の暗号化は、配送トラックの荷台に鍵をかける仕組みであって、倉庫に着いた荷物は開封されて棚に並ぶわけです。「SSL で暗号化しています」という説明は、この層のことしか言っていません。現在ではほぼすべてのまともなサービスが満たしている最低条件で、安心の根拠としては弱い情報です。

層2: 保存の暗号化 — 鍵は事業者の手の中

多くのサービスは、サーバに保存するデータも暗号化しています。データセンターからディスクが盗まれた、廃棄したディスクからデータが復元された、といった事故に備える層で、これも重要な防御です。

問題は鍵の置き場所です。保存の暗号化では、暗号化と復号を行うのはサーバ自身なので、鍵も事業者側にあります。事業者は業務としてデータを復号できますし、事業者に侵入した攻撃者が鍵ごとデータを盗む可能性も残ります。従業員の不正アクセス、捜査機関からの開示要求、事業者自身によるデータ解析(広告や機能改善のため)も、技術的には可能な状態です。実際にやるかどうかは事業者の規約と倫理の問題であって、技術の保証ではありません。

この層を事業者が正直に書くとどうなるかは、Google Cloud の文書が分かりやすい例です。保存されるすべての顧客コンテンツを利用者が何もしなくても暗号化し、ストレージ層では AES-256 を使うと述べたうえで、その暗号化に使う鍵は Google が所有し管理している、と明記しています(デフォルトの保存データの暗号化)。強い暗号方式と、鍵は事業者が持つという事実は、このように両立します。

「サーバ上のデータは暗号化して保管しています」という説明は、この層を指していることが多いです。嘘ではありませんが、「事業者にはあなたのノートが読める」という事実と両立する説明だ、という点を押さえてください。

層3: E2E は「鍵を事業者に渡さない」

エンドツーエンド暗号化(E2E)は、発想を転換します。データを端末の上で暗号化してから送り、復号の鍵を端末にしか置かない。サーバが保管するのは、鍵なしでは意味を成さない暗号文だけです。事業者にも、事業者に侵入した攻撃者にも、サーバを差し押さえた誰かにも、中身は読めません。「エンド(あなたの端末)からエンド(あなたの別の端末)まで」暗号が解かれない、という意味の名前です。

この方式は、メッセージアプリの Signal や、冒頭で触れた iCloud の「高度なデータ保護」で使われているのと同じ考え方です。かつて E2E は暗号に詳しい人向けの特別な選択肢でしたが、メッセージアプリでの普及を経て、いまでは私的な通信や記録を扱う分野の最も強い保護水準として確立しています。大手プラットフォームが標準機能やオプションとして E2E を提供するようになった流れは、「事業者すら読めない設計」が特殊な要求ではなく、私的なデータの置き場として妥当な水準になったことを示しています。

ノートアプリの例では、TheNote がこの方式です。ノートは端末上で AES-256-GCM により暗号化されてから送られ、鍵は macOS のキーチェーンと Android の Keystore にのみ保存されます。サーバは「読めない郵便受け」として同期の中継だけを担い、サーバ上のデータは運営者にも復号できません。これは倫理の話ではなく、設計上そうなっているという話です。

E2E の本質は、信頼の置き場所の変更です。層2までは「事業者が読める状態のデータを、事業者が読まないと信頼する」構図でした。E2E では「事業者がそもそも読めない」ので、事業者の善意を信頼する必要がなくなります。事業者の方針転換、買収、情報漏えい事故があっても、暗号文しか漏れません。守りの根拠が約束から数学に変わる、と言い換えてもよいと思います。

ここまでの3層を表に整理します。

1. 送信する端末で、内容を暗号化します。
2. 途中のサーバーには、復号用の鍵を渡さず暗号文を保管します。
3. 受け取る端末で、必要な鍵を使って内容を読みます。

実例: iCloud の「標準」と「高度」で何が変わるか

層2と層3の差を、ひとつのサービスの中で見比べられるのが iCloud です。Apple の説明によれば、初期設定の「標準のデータ保護」では iCloud のデータは暗号化されるものの、暗号化キーは Apple のデータセンターに保管され、新しいデバイスでのサインイン時やパスワードを忘れたあとのデータ復旧時には、ユーザに代わって Apple がデータを復号できます。メモについては本記事でいう層2に相当します。ただし標準でも、キーチェーンなど一部のカテゴリはE2Eで保護されます。一方、オプションの「高度なデータ保護」を有効にすると、iCloud バックアップやメモを含む大半のデータがエンドツーエンド暗号化の対象になり、暗号化キーにアクセスできるのはユーザ本人の信頼できるデバイスだけになります。その代わり、有効にする前に復旧用連絡先か復旧キーを少なくとも1つ設定するよう案内され、アカウントにアクセスできなくなったときは Apple ではなく自分でその復旧方法を使って対処することになります(iCloud のデータセキュリティの概要、高度なデータ保護を有効にする方法)。

「事業者が鍵を持つか」と「復旧を自分で担うか」が一組で切り替わるこの構造は、この記事の3層の説明そのものです。なお、高度なデータ保護を有効にしても、ファイルやオブジェクトの変更日時やチェックサムといったメタデータは標準のデータ保護のままだと Apple は明記しており、これは後述する「メタデータの限界」の実例でもあります。

鍵はどこにあり、どう増えるのか

E2E を理解する残りのピースは、鍵の管理です。鍵は端末の中の保護された領域(iOS/macOS ならキーチェーン、Android なら Keystore)に保存されるのが一般的です。この領域は OS が守っていて、他のアプリからは読み出せません。Apple の文書では、キーチェーン項目が AES-256-GCM の鍵で暗号化され、秘密値の鍵は常に Secure Enclave を介して扱われること、キーチェーン項目の共有は同じデベロッパによるアプリ間でのみ可能なことが説明されています(キーチェーンのデータ保護)。Android でも、Keystore の鍵マテリアルはアプリのプロセスに入ることがなく、対応する端末ではセキュアハードウェアにバインドして外部へ漏れないようにできると開発者向け文書に書かれています(Android Keystore システム)。

複数端末で同期する場合は、新しい端末に何らかの安全な方法で鍵を届ける必要があります。方式はサービスによって異なり、既存端末での承認操作、QR コードの読み取り、リカバリーコードの入力などが使われます。いずれの方式でも共通するのは、「サーバは鍵の受け渡しを仲介するだけで、鍵そのものを読める形では持たない」よう設計されていることです。既存端末の承認やコード入力は、端末追加を保護する仕組みになり得ます。ただし操作があることだけではE2Eの実装を証明できません。

そして、鍵の管理を事業者がしない以上、鍵の最終的な責任者は利用者です。多くの E2E サービスは、端末をすべて失ったときの命綱としてリカバリーコード(復旧キー)を発行します。このコードの保管が、E2E 利用者のいちばん重要な仕事になります。後述の運用のところで具体策を挙げます。

パスワードと鍵の関係

「鍵」と「パスワード」がどう関係するのかも、よくある疑問なので触れておきます。暗号化に実際に使われる鍵は、長いランダムなデータであって、人間が覚えるパスワードそのものではありません。人間に覚えられる長さの文字列は、暗号の鍵として直接使うには弱すぎるからです。

サービスによっては、パスワード(またはパスフレーズ)から鍵導出と呼ばれる計算を通じて鍵を作る設計を採ります。この設計では、同じパスワードからいつでも同じ鍵が再現できるので、新しい端末でパスワードを入力するだけで復号が可能になります。便利な半面、パスワードの強度がそのまま暗号の強度の入り口になります。短く推測しやすいパスワードは、暗号文を手に入れた攻撃者による総当たりの標的になるため、E2E でパスワード由来の鍵を使うサービスでは、長いパスフレーズを設定する価値が普段以上に大きくなります。

一方、端末の保護領域にランダム生成した鍵を置く設計(前述のキーチェーンや Keystore を使う方式)では、鍵はパスワードと独立しています。この場合、パスワードはアカウントへのログインを守る役、鍵はデータの中身を守る役、と役割が分かれます。自分の使うサービスがどちらの設計かを知っておくと、「パスワードを変えたら復号できなくなるのか」「新端末で何が必要か」といった疑問に自分で答えられるようになります。

ノートという用途ならではの事情

E2E はメッセージアプリで有名になった技術ですが、ノートに適用するときには、メッセージとは違う事情がいくつかあります。

まず、通信相手がいないことです。メッセージの E2E は、他人との間で安全に鍵を取り交わすという難しい問題を解く必要があります。ノートの同期は「自分の端末」から「自分の別の端末」への通信なので、鍵の共有は自分の管理下で完結します。構図が単純な分、ノートの E2E は堅実に実装しやすい領域だと言えます。

次に、データの寿命が長いことです。メッセージは流れていきますが、ノートは何年も書き溜め、何年後にも読み返します。つまり「いま安全」だけでなく「10年後も取り出せて読める」ことまで含めて設計と運用を考える必要があります。E2E の強い保護と、長期保存に必要なバックアップや可搬性は、意識して両立させないと衝突します。この記事の運用の節とバックアップの記事が、その両立の具体策です。

最後に、書く内容の私的さの濃度です。メッセージには相手がいる分、ある程度の対外性がありますが、ノートは完全に自分だけの空間で、検閲のない本音が集まります。だからこそ、ノートは E2E の保護が最も似合うデータだと考えて、TheNote では E2E を後付けのオプションではなく前提として設計しました。読まれる可能性を意識しながら書いた本音は、もう本音ではないからです。

E2E が守るもの、守らないもの

E2E は強力ですが、万能の魔法ではありません。何から守られ、何からは守られないのかを正確に知っておくことが、過信と不安の両方を防ぎます。

保護の対象は、事業者が復号鍵を持たない形で暗号化された本文などです。事業者の内部者、サーバへの侵入者、サーバの差し押さえ、事業者のデータ解析。これらに対して、適切な実装で暗号文と復号鍵が分離されていれば、サーバ上の暗号文だけから内容を読むことは防げます。対象外のメタデータや端末の侵害は別に考えます。ノートの内容が「サービス側の事情」で漏れる経路を、まとめて塞ぐのが E2E です。

守られないものの筆頭は、端末そのものです。暗号はサーバに対する守りであって、端末の上ではノートは読める状態で表示されます。端末にロックをかけていなければ、端末を手にした人は E2E ノートを普通に読めます。端末がマルウェアに感染していれば、画面や入力を盗まれる可能性もあります。E2E ノートの安全は、端末のロック(パスコード・生体認証)と OS を最新に保つ習慣とセットで初めて成立します。

もうひとつ、メタデータの限界も知っておく価値があります。E2E でもサーバは、いつ・どの端末が・どれくらいのサイズのデータを同期したか、という周辺情報は扱います。中身は読めなくても、利用の痕跡は残る。iCloud の高度なデータ保護でも変更日時やチェックサムが標準のデータ保護のままなのは、まさにこの層の話です。その影響は用途によって異なりますが、「何もかも見えなくなる」という理解は正確ではない、という線引きです。

最後に、入力の段階も暗号化の外です。ノートに書く文字は、キーボードアプリを通って入力されます。キーボードアプリが入力内容をクラウド送信する設計なら、E2E ノートに書いた内容も入力段階で外に出ることになります。この経路の話はキーボードとプライバシーの記事で詳しく扱っています。

E2E かどうかを見分ける質問

サービスの説明を読むとき、次の2つが確認ポイントです。

• 暗号化はどこで行われるか(端末上か、サーバ到着後か)
• 事業者単独で中身を復号できるか。復旧には利用者の端末や復旧情報が必要か

2つ目では、アカウントの復旧と暗号鍵の復旧を分けます。利用者の信頼済み端末や復旧キーを使って鍵を取り戻す仕組みなら、復旧できても事業者が本文を読めるとは限りません。「リセットできるか」だけでなく、誰がどの情報を使って復号するかを公式文書で確認します。AppleもE2Eで保護するデータについて、デバイスのパスコードや復旧用連絡先、復旧キーを使う方法を説明しています(iCloud のデータセキュリティの概要)。

補助的な確認ポイントもあります。技術的な仕組みを解説した文書(セキュリティホワイトペーパーや技術ブログ)を公開しているか。使っている暗号方式(AES、公開鍵暗号など)を具体名で書いているか。第三者の監査やソースコード公開があるか。これらは必須条件ではありませんが、「E2Eです」と一言書くだけのサービスより、検証の材料を出しているサービスのほうが信頼の根拠は厚くなります。

実際の説明文でこの質問を使うとどうなるか、練習してみます。「通信は SSL/TLS で保護され、サーバ上のデータは暗号化して保管されます」——層1と層2の説明であり、E2E への言及はありません。「あなたのデータは端末上で暗号化され、当社もその内容を閲覧できません」——鍵の置き場所に踏み込んだ、E2E を示す記述です。「万一パスワードをお忘れの場合も、ご本人確認のうえデータを復旧いたします」——この文面だけでは、事業者単独の復旧なのか、利用者の鍵を使う復旧なのかは判断できません。同じ「暗号化」という言葉でも、文の構造を見れば層が判別できることが分かると思います。

注意したいのは「軍事レベルの暗号化」「銀行レベルのセキュリティ」といった形容です。これらは強度の印象を与えますが、鍵をどこに置くかという核心には何も答えていません。前述の Google Cloud の例のとおり、AES-256 は層2(事業者が鍵を持つ保存暗号化)でも普通に使われる方式なので、暗号アルゴリズムの名前だけでは E2E かどうかは分かりません。見るべきは方式の強さではなく、鍵の置き場所です。

E2E の代償と付き合い方

E2E は「事業者に頼れない」ことの裏返しでもあります。代償は主に3つあります。

第一に、鍵を失えば誰にも助けられないことです。全端末とリカバリーコードを同時に失うと、サーバにデータが完全な形で残っていても、それを読める人は宇宙に存在しなくなります。これは欠陥ではなく E2E の定義そのものですが、利用者が負う責任としては最大のものです。

第二に、サーバ側の機能が制限されることです。サーバはデータを読めないので、サーバでの全文検索、サーバでの AI 処理、ブラウザからの閲覧などは、どこで復号するかを含めた設計が必要です。ブラウザ内で復号するE2Eの構成もあり、Web版があるだけで保護が弱いとは言えません。E2E ノートアプリの検索や整理の機能は端末側の実装に依存するため、アプリによって使い勝手の差が出やすい部分です。

第三に、共有や共同編集が複雑になることです。他人と安全に鍵を交換する仕組みが必要になるため、E2E を保ったままの共有機能は技術的なハードルが上がります。共有を多用する用途なら、そもそも E2E が適した道具なのかを含めて考える必要があります。

これらの代償を踏まえると、付き合い方はこう整理できます。人に見せる前提の情報や、失って困るが秘匿性の低い情報は、通常のクラウドサービスでよい。誰にも読まれたくない私的な記録こそ、E2E に置く価値がある。全部を E2E にする必要はなく、守りたいものを守れる場所に置く、という使い分けです。

なお、代償の重さは固定ではありません。端末側の全文検索が十分に速ければ第二の代償は体感されませんし、リカバリーの仕組みが丁寧に設計されていれば第一の代償も現実的に管理できます。つまり「E2E だから不便」と一括りにするのは正確ではなく、代償をどれだけ工学で吸収できているかがアプリごとの実力差になります。E2E を検討するときは、暗号の有無だけでなく、この吸収の出来まで見て選ぶことをすすめます。

E2E ノートを使うときの運用

E2E ノートを安心して使うために、最初に整えておくことを手順にします。

1. リカバリーコードが発行されたら、その場で保管する。紙に書いて自宅の安全な場所に置くか、パスワードマネージャーに入れる。ノートアプリ自体の中には絶対に保存しない(ロックアウト時にコードごと読めなくなるため)
2. 端末のロック(パスコード・生体認証)を有効にする。E2E の守りは端末の無防備を補ってくれません
3. 可能なら2台目の端末を登録しておく。1台が故障・紛失しても、もう1台が鍵を持っているので復旧が容易になります
4. 復号済みの状態でのローカルエクスポートを定期的に取る。端末と鍵を同時に失う事故への最後の備えです。取り方と保管の注意はバックアップの記事にまとめてあります
5. エクスポートしたファイルは平文なので、自分しかアクセスできない場所に置く

とくに4番は、E2E 利用者ほど重要です。通常のクラウドサービスなら「パスワードを忘れたらリセット」という救済が最後にありますが、E2E にはそれがありません。E2E の強さを享受しながら、自分で自分の救済路を確保しておく。プライバシーの強さと、自己責任の重さは同じコインの裏表です。この5つの手順は、最初に30分かけて整えれば、その後も端末や復旧方法の変更時に見直します。エクスポートの間隔は、失ってよい変更量に合わせてください。

よくある失敗と対処

• リカバリーコードをスクリーンショットで撮って、そのまま忘れる。対処: スクリーンショットは端末と運命を共にするので、命綱になりません。撮った日のうちに、パスワードマネージャーか紙へ移してください
• 「E2Eだから」と端末ロックを軽視する。対処: ロックなしの端末を置き忘れることも、内容が読まれる経路になります。守りの順序はまず端末、次にクラウドです
• 機種変更の前に古い端末を初期化してしまう。対処: E2E サービスでは、古い端末が新しい端末へ鍵を渡す役を担うことがあります。機種変更では「新端末の同期が完全に済んでから旧端末を初期化」の順序を必ず守ってください
• 家族と共用の端末に E2E ノートを入れる。対処: E2E は端末上では平文です。共用端末では、アプリ自体のロック機能(パスコードや生体認証での起動制限)があるものを選ぶか、私的なノートは個人の端末だけに置きます
• 「暗号化」の一語で安心して確認を省く。対処: この記事の2つの質問(どこで暗号化されるか、リセットで復元できるか)を、契約前に説明ページで確認する習慣をつけてください。確認に5分もかかりません

よくある質問

E2E でないノートアプリを使うのは危険ですか

用途によります。大手事業者の通常のクラウドサービスも、通信と保存の暗号化、アクセス管理など、相応の防御を積んでいます。買い物メモや仕事の議事録をそこに置くことを危険と呼ぶのは大げさです。一方、日記や健康・信条に関わる記録のように「事業者にすら読まれたくない」水準の情報は、E2E に置く理由があります。リスクは情報の性質で決まるので、全部を一律に語らないのが正確な態度です。

パスワードが強ければ E2E でなくても同じでは

守る対象が違います。パスワードは、あなたのアカウントへの不正ログインを防ぐ道具です。E2E は、正規のアクセス権を持つ側(事業者)からも中身を守る仕組みです。どんなに強いパスワードを設定しても、層2のサービスでは事業者はデータを復号できます。両者は代替関係ではなく、併用するものです。E2E サービスでも、ログインパスワードと二要素認証は依然として重要です。

スマホの紛失に E2E は役立ちますか

紛失そのものへの守りは、E2E ではなく端末のロックと遠隔消去が担います。E2E が効くのは、紛失後にノートの中身がクラウド経由で漏れない、新しい端末で復旧するまでサーバ上のデータが誰にも読めない、という部分です。紛失に備える実務としては、端末ロックの徹底、OS の「デバイスを探す」機能の有効化、そして2台目の端末かリカバリーコードの確保、の3点を揃えてください。

同期の速さや競合処理は E2E だと悪くなりますか

暗号化と復号の処理は現代の端末には軽い仕事なので、体感速度の差はまず出ません。競合処理(複数端末で同時編集したときの解決)は、E2E かどうかよりも同期設計の出来に左右されます。サーバが中身を読めない分、競合の解決は端末側で行う設計になりますが、これは実装の問題であって、利用者から見た優劣は個々のアプリの完成度次第です。同期の仕組み全般は同期方式の記事で解説しています。

E2E のサービスが終了したらデータはどうなりますか

サーバ上の暗号文は、サービスが消えれば一緒に消えます。ただし E2E の設計上、あなたの端末には復号済みのデータ(または復号できる鍵とデータ)が残っているので、端末に必要なデータと鍵が残り、アプリが利用できれば内容を取り出せる可能性があります。すべての添付が端末に保存済みとは限らないため、終了前に確認します。やるべきことは、終了告知が出たら早めに全ノートをエクスポートして手元に確保することです。逆に言えば、端末を失った状態でサービスも終了する、という重なる場合には、復旧がさらに難しくなります。定期エクスポートの習慣は、この最悪の組み合わせに対する保険でもあります。

途中から E2E のアプリに乗り換えられますか

できます。現在のアプリからエクスポートして、E2E アプリにインポートするだけで、過去のノートも E2E の保護下に入ります。注意点は2つ。移行前のデータは移行元のサーバに残っている可能性があるので、必要ならアカウント削除まで行うこと。そして移行時に使った中間ファイル(エクスポートした平文)を、移行完了後に消しておくことです。乗り換えの手順全体は移行のチェックリストが使えます。

次の一歩

まず、いま使っているノートアプリの説明ページかヘルプで、2つの質問の答えを探してください。暗号化はどこで行われるか。パスワードリセットで中身は復元されるか。サーバ側の暗号化だけを説明しているなら、E2Eの有無は追加確認が必要です。パスワードリセット後の復元可否だけでは判定しません。それで足りる使い方をしているなら問題ありませんし、読まれたくない記録を置いているなら、E2E のサービスへ移すか、その記録だけ置き場所を変える。

あわせて、iPhone や Mac を使っているなら、自分の iCloud が標準と高度のどちらになっているかを見ておくと、層2と層3の違いを自分のデータで実感できます。Apple の手順では、iPhone は「設定」からユーザ名、「iCloud」、「高度なデータ保護」の順にたどり、Mac は Apple メニューの「システム設定」からユーザ名、「iCloud」、「高度なデータ保護」の順です(高度なデータ保護を有効にする方法)。有効にする場合は復旧用連絡先か復旧キーの設定が前提になるので、運用の節の1番(リカバリーコードの保管)をそのまま適用してください。自分のデータがどの層に置かれているかを知っていること——それが、クラウド時代のプライバシーの出発点です。

「ログインできる」と「ノートを読める」を分けて考える

新しい端末でアカウントへ入れたのに、過去のノートが読めない場面を想像してください。認証は「そのアカウントを使ってよい人か」を確認する処理です。一方、復号には暗号化された内容を読める鍵が必要です。サービスによって両者の連携方法が違うため、ログイン画面を通れたことだけでは、過去データを復元できたとは判断できません。

確認には、機密情報を含まない検証用ノートを使えます。本文と添付を新しい環境で実際に開き、公式の復旧手順と照合してから古い端末の扱いを決めます。「同期済み」という表示だけでなく、読むための条件がそろったかを見るのがポイントです。

保存・共有・書き出しを一つの経路として見る

ノート本体がE2Eで保護されていても、その文章をどこかへコピーした後は、コピー先の扱いを確認する必要があります。たとえば架空の打ち合わせメモを共有文書へ貼り付けたなら、共有文書の閲覧権限や保存方式が関係します。元のノートの保護が、貼り付け先へ自動的に引き継がれるわけではありません。

このため、保存先を選ぶときは「書く」「同期する」「相手へ渡す」「バックアップする」の順に、本文がどこへ移るかを書き出すと理解しやすくなります。すべてを難しい技術用語で記録する必要はありません。「共有用には必要な部分だけを別にする」「復旧情報はこのノート以外で管理する」といった運用の形まで決まれば、選んだ保護を保ちやすくなります。

説明に不明な点がある場合は、暗号方式の名前を推測するより、「対象は本文だけか」「公開共有したときも同じ保護か」「事業者だけで復号できる鍵を持つか」と、具体的な範囲を確認してください。

参考リンク

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 — TLS が盗聴・改ざん・偽造を防ぐ通信路の保護であること
• Google Cloud: デフォルトの保存データの暗号化 — 保存データを AES-256 で暗号化し鍵は Google が所有・管理すること
• Apple: iCloud のデータセキュリティの概要 — 標準と高度なデータ保護の鍵の置き場所、復旧、メタデータの扱いの違い
• Apple: iCloud の高度なデータ保護を有効にする方法 — 有効化の設定手順と、復旧用連絡先・復旧キーが前提になること
• Apple: キーチェーンのデータ保護 — キーチェーン項目の暗号化、Secure Enclave、アプリ間共有の制限
• Android Developers: Android Keystore システム — 鍵マテリアルがアプリプロセスに入らず、セキュアハードウェアに束縛できること