認証付きバックアップ
後で何かを書き出した時点からではなく、作成した瞬間から信頼できるタイムスタンプが付いたバックアップ。
要点
バックアップのとき、Text2Store は独立したタイムスタンプ局に、その瞬間の立ち会いを依頼できます。その証明はその後ずっとバックアップの中に残るので、誰でも後から、バックアップの内容が変更なく存在していたことを、たまたま何かを書き出した日からではなく作成した日から証明できます。必要なのはチェックボックス 1 つ、インターネットはその瞬間だけ、料金は無料でバックアップに含まれます。
認証付きバックアップとは
Text2Store のバックアップは、もともと取り込んだすべてのもののチェックサムを記録しており、後でファイルが変わったかどうかをアプリが判断できます。認証付きバックアップは、そのチェックサムを書き込むまさにその瞬間に、もう 1 つのことを加えます。そのフィンガープリントを独立したタイムスタンプ局(DigiCert、オープン規格 RFC 3161 を使用)に送り、署名された返答をバックアップの隣に保存します。その返答は、バックアップが取り込んだとおりの形で、その時刻に存在していたことの信頼できる証人です。バックアップ自体は何も変わりません。ファイルも速度もすべて同じで、小さなファイルが 1 つ増えるだけです。
これはアーカイブ(コンピュータに保存されたバックアップ)の性質で、検証済み書き出し(誰かに渡す .zip)とは別のものです。両者は連携します。後述をご覧ください。
オンにする
認証は、設定の認証付きバックアップのスイッチで切り替えます。初期設定でオンになっています。オフにするまで、メニューから始めたものも含め、そのコンピュータでのすべてのバックアップに適用されます。バックアップの前には毎回、バックアップのダイアログがそのバックアップが認証されるかどうかを示し、設定で変更するためのリンクも表示します。それ以外に、デバイスごとやバックアップごとに設定するものはありません。
認証付きバックアップを作成する瞬間には、インターネット接続が必要です。小さなリクエストで 32 バイトのフィンガープリントだけを送り、メッセージやファイルは決して送りません。オフラインの場合や、タイムスタンプサービスに接続できない場合でも、Text2Store はバックアップを失敗させたり、証明書を偽造したりはしません。バックアップを通常どおり完了して保持し(タイムスタンプがないだけで捨てるには、バックアップは貴重すぎます)、はっきりと伝えます。「バックアップは保存されましたが、認証されていません。」アーカイブは完全で安全です。通常の認証なしのバックアップとして残るだけです。認証付きのものが必要なら、オンラインになってからもう一度バックアップしてください。
チェックマークの意味
認証はどこでも同じ小さなバッジで表示されます。チェックマーク付きのロゼット形の印です。警告ではなく、バックアップの来歴についての事実なので、あえて控えめにしています。表示されるのは次の 3 か所です。
- バックアップの一覧では、認証付きアーカイブの日付の横に小さな灰色のチェックマークのバッジが付きます。暗号化されたアーカイブの鍵アイコンと同じくらいの控えめさです。カーソルを合わせると「認証付きバックアップ:作成時刻が信頼できるタイムスタンプで固定されています」と表示されます。
- 会話の一覧の下では、開いているバックアップが認証付きの場合、会話数とメッセージ数の下に、同じバッジが緑色で「認証付きバックアップ」の文字とともに表示されます。
- 検証済み書き出しのダイアログでは、主張に合わせた色でバッジが再び表示されます。元のアーカイブが認証付きなら緑色で「認証付きバックアップ由来」、そうでなければ灰色で「本日時点での検証」です。この違いが書き出しにとって実際に何を意味するかは、後述します。
証明できること
通常のバックアップでも、バックアップ以降にファイルが変わったかどうかは後で確認できます。ただし照合の基準となる記録は、守るべきファイルのすぐ隣にあります。元のファイルにアクセスできる人なら、理論上はファイルを編集し、その記録を黙って作り直して一致させることができます。認証付きバックアップは、証人を誰の手も届かない外側に置くことで、この穴をふさぎます。タイムスタンプは DigiCert の秘密鍵で署名され、その鍵は DigiCert 以外の誰も持っていません。あなたも、Text2Store も、攻撃者も持っていません。後からローカルの記録を作り直すとフィンガープリントが変わり、封印されたタイムスタンプと合わなくなるので、不一致が見つかります。
これが「バックアップの後でメッセージを編集してから渡すこともできたはずだ」への答えです。検証済み書き出しのタイムスタンプが「書き出した後で編集した」への答えになるのと同じで、固定する時点が 2 段階早い、つまり書き出し時ではなくバックアップ時だというだけです。
なぜバックアップ時にしかできないのか
認証は後からバックアップに追加することはできず、Text2Store がその方法を提供することもありません。後から取得したタイムスタンプは、バックアップが後の時点で存在していたことしか証明せず、それこそ認証が埋めるべき穴だからです。そのため、チェックボックスはバックアップダイアログの 1 か所にしかありません。認証されていない大切なバックアップがある場合は、チェックを入れて新しく作成するしかありません。
検証済み書き出しをどう強化するか
認証は検証済み書き出しの条件ではありません。認証の有無にかかわらず、どのバックアップからでも改ざんを検知できる .zip を書き出せ、その有用性もこれまでどおりです。変わるのは、書き出しの証明がどこまでさかのぼるかです。
- 認証付きバックアップから:書き出しはバックアップ自体の作成時のタイムスタンプを引き継ぐので、証明の連鎖は書き出し時だけでなくバックアップ時までさかのぼります。書き出しに含まれる証明書にもそうはっきり書かれます。添付ファイルはその日に信頼できるタイムスタンプが付いたバックアップとバイト単位で同一で、記録はそこから取り出されたものだと。
- 認証なしのバックアップから:書き出しは通常どおり書き出し時にタイムスタンプが付き、改ざんを検知できる点もこれまでと同じです。ただ、バックアップそのものを証明したものがないため、バックアップから書き出しまでの間に何があったかについては何も言えません。書き出しは正直にそう書きます。「本日時点での検証です。このバックアップは作成時に認証されていないため、本日より前の整合性は証明されません。」
いずれの場合も書き出しは本物で、独立して検証できます。認証はより早い時点の固定を加えるだけで、何かを取り去ることはありません。
この「バイト単位で同一」という主張は、最初の認証を鵜呑みにしたものではありません。認証付きバックアップから書き出しを作る前に、Text2Store はバックアップのメッセージデータベース、ファイル索引(どの添付ファイルがどのメッセージに属するか)、書き出しが依存するほかの記録を、バックアップ自身の整合性の基準と照らして、バックアップ作成時の一度だけでなく、その時点で改めて独立に確認します。認証後にどれかが変わっていれば検出され、バックアップの実際の中身と合わなくなった認証バッジを黙って引き継ぐのではなく、書き出しの作成を拒否します。
証明できないこと
検証済み書き出しと同じ正直な限界が、1 段階早く、ここにも当てはまります。
- バックアップ前に iPhone が改ざんされていなかったこと。認証が固定するのは「Text2Store が取り込んでから変わっていない」ことであって、「取り込んだときデバイスが真実を示していた」ことではありません。
- どう受け取られるか。Text2Store は、認証付きバックアップやそこからの書き出しが、特定の受取人や手続きで受け入れられると主張することはありません。記録がどれだけの重みを持つかは、常に受け取る側が決めることです。詳しくは検証済み書き出しのページをご覧ください。
- この機能ができる前に作られたバックアップや、認証をオフにした状態で作ったバックアップについては何も。認証は、仕様としてさかのぼって適用されることはありません。
技術的な基盤
認証は、検証済み書き出しと同じオープン規格、DigiCert が署名する RFC 3161 の信頼できるタイムスタンプを使い、同じアプリ内の検証機能で確認します。バックアップの整合性記録のハッシュを再計算し、署名が固定された DigiCert のルートまでつながっていることを確かめ、証明された時刻に有効だったかを確認して、結果を報告します。仕組み、規格、標準的なツールですべて手作業で確認する方法は、検証済み書き出しのページの技術的な説明に詳しく書かれています。両方の機能は、まったく同じ検証コードと信頼の基点を共有しているからです。
法的助言ではありません
このページは一般的な情報で、法的助言ではありません。Text2Store を使っても、いかなる専門的な関係も生じません。認証付きバックアップやそこからの書き出しを法的な案件で頼りにするつもりなら、それはあなたと、お住まいの法域の資格ある弁護士との間の話です。ここにある内容は、そうすべきか、どうすべきかについての助言ではありません。
トラブルシューティング
- 「検証済み書き出しの作成を拒否しました:… このアーカイブの整合性の基準と一致しなくなりました …」
- 前述の書き出し前のチェックで、認証付きバックアップが依存するファイルの 1 つが認証後に変わっていたことがわかりました。保存先のディスクの劣化かもしれませんし、改ざんかもしれません。認証された内容と合わなくなったアーカイブから書き出しを作る代わりに、書き出しは拒否されます。そのアーカイブの検証ボタンをクリックすると、同じ診断をより詳しく見られます。ディスクの劣化だった場合は、新しくバックアップすれば、きれいな認証済みのコピーが得られます。影響を受けたアーカイブとほかのアーカイブには、それ以外の影響はありません。
- 「… ディスク上にもうありません。」
- バックアップの整合性記録が想定しているファイルが見つかりません。たいていは、アーカイブのフォルダ内のものを手で削除したことが原因です。上と同じく、そのアーカイブを検証して詳細を確認し、そのデバイスの認証付きコピーが必要ならもう一度バックアップしてください。
関連情報
PDF に書き出す、eDiscovery レビュー用の RSMF、暗号化バックアップ。
ご質問は?
hello@text2store.com までメールでお問い合わせください。