#1485: Catalina 登場、tvOS 13 で Picture in Picture、iOS 13 で Wi-Fi 接続、Apple のパスコード要求を解説

Apple は今日 macOS 10.15 Catalina をリリースした。その結果、HomePod 用の iOS 13 及び Apple Watch Series 1 と Series 2 用の watchOS 6 だけが、何時出されるかわからないベイパーウェアとして残された。Catalina は System Preferences > Software Update では自分自身を 8.09 GB ダウンロードだと宣伝しているが、その App Store ページでは 4.9 GB だけであるとしている。何が新しくなったのかの概観については、"macOS Catalina で、Mac はもう孤島じゃない" (3 June 2019) を参照されたい。

我々は、Michael Cohen が TidBITS Slack グループで指摘したように、Apple は Catalina のリリースを、ポルトガルの探検家 Juan Rodriguez Cabrillo が Santa Catalina Island を Spain の領土だと 7 October 1542 に宣言した 477 回目の記念日に合わせるために意図的にリリース日を遅らせたのかどうか、本当に知りたいと思っている。勿論、それは発見ではなかった - この島には原住民である Pimugnans が紀元前 7000 年から住んでいた。

リリース日が歴史的な一致かどうかに拘らず、今や皆さんは何時 Catalina にアップグレードすべきかの問いに直面している。私は "何時" であって "かどうか" と言ったのではないことに注目して欲しい。何故ならば、新しい Mac を買う、最新のソフトウェアが必要となる、或いは iOS との適合性の様な何らかの理由で、どこかの時点でアップグレードしなければならない局面に遭遇するからである。どうせやるのなら、受動的にではなく能動的にやった方が良い。その時が来たら、Joe Kissell の Take Control of Upgrading to Catalina にある進言に従うことをお勧めする。

いずれにしろ、多くの人に対して、我々は色々な理由からアップグレードをしばらく遅らせることをお勧めする：

• Catalina は 32-bit アプリを走らせない： TidBITS 読者なら、この時点でこの知らせに驚く人はないであろう。もし 32-bit アプリに依存しているのであれば、それらをアップグレードする (高くつくかもしれない)、代替策を見つける (高くつくかもしれないし、習熟する必要がある)、或いはそれらを仮想マシン上で走らせる ("Catalina への移行： 手持ちの 32-Bit Mac アプリは Parallels で動かす" 18 September 2019 参照) 必要があるであろう。もし Mojave をダウンロードする必要があるのであれば、Apple はそのやり方を説明するサポート書類を出している。
• バックアップアプリの中には未だ Catalina に対応していないものがある： Catalina での大きな変更の一つは、macOS が、皆さんのアプリや書類を保存する書き込み可能なデータボリュームとは分けられれている読み取り専用のシステムボリュームから走るやり方である。この変更が、他のものと相まって、バックアップアプリに対して問題を生じさせた。開発者たちはこれを考慮に入れようとしているが、使っているバックアップアプリが対応する前に Catalina にアップグレードするのは愚かというものであろう。重要なアップデートに対しては、TidBITS Watchlistに注意を払って欲しい。例を挙げると、Carbon Copy Cloner 5.1.10 及びそれ以降は Catalina に対応しており、Retrospect 16.5 もそうであるが、Shirt Pocket は SuperDuper の Catalina 対応性に関する声明を今後出さなければならない。
• Catalina の認証要件が問題を引き起こすかもしれない： Apple が Catalina でセキュリティを強化した方法の一つは、Mac App Store の外側で配布されるアプリが走るためには Apple による認証を必要とすることである。これらの要件は、以前に配布されているソフトウェアには適用されないので、皆さんの Mac 上に既に存在するこれまでのアプリは引き続き走るであろうが、Catalina により古い、認証されていないアプリをインストールすることは出来ないであろう。
• Catalina はこれ迄以上にアプリに許可要請を強要する： 繰り返すが、セキュリティとプライバシーの強化の必要性から、Apple は、アプリに Catalina では以前のバージョンの macOS よりも多くの許可を求めることを要求している。Catalina では、アプリは Desktop 及び Documents フォルダー、iCloud Drive、そして外部ボリュームのファイルにアクセスするために許可を求めなければならない。加えて、アプリがキーボード操作、或いはスクリーンショット、或いはスクリーン録画を捉える前に、注意喚起される。これはセキュリティのためには良いが、より以前のソフトウェアはどう尋ねて良いか知らない、或いはその要請を拒否した時正しく働かない可能性がある。
• 後方互換性に関して予期せぬ問題が起こり得る： この懸念は純粋に推測の域を出ないものだが、過去には Mac を使う事業所を痛い目に合わせたことがある。要するに、もし Catalina にアップグレードすると、あなたが依存しているアプリもアップグレードする必要が出るかもしれない。そしてもしその新しいバージョンが書類を古いバージョンでは読めないフォーマットで保存するとすると、それは直ちにはアップグレードすべきではない或いは全くアップグレード出来ない Mac ユーザーには問題となり得る。
• 今年の Apple の OS リリースはこれ迄の所バグだらけであった： Apple のソフトウェアテストは、公開ベータでのユーザーからの報告と相まって、メジャーなオペレーティングシステムのリリースにおいては、歴史的には殆どの一般的で厄介なバグを見つけ出しそして修正するのに良い仕事をしてきた。それが、今年は２週間も経たないうちに、Apple は既に iOS 13.0, 13.1, 13.1.1, 及び 13.1.2; iPadOS 13.1, 13.1.1, 及び 13.1.2; そして watchOS 6.0 及び 6.0.1 (Apple Watch Series 3 そしてそれ以降に対してのみ) をリリースしている。Apple が時を置かずにバグを修正するのは嬉しいが、多少リリースが遅れてもバグの少ないものの方が好ましい。

Catalina は、Apple が iOS, iPadOS, そして watchOS で修正に駆けずり回った種類のバグに痛めつけられるのかどうかは知る術もないが、慎重である価値はある。我々は、早期導入者でない限り、.1 か .2 リリース迄待つのが賢明だとしばしば進言してきた；これらが出た時、我々のアップグレード進言もそれに見合って変更していく。慎重に行くことを勧めているのは何も我々だけではない - Six Colors では、Jason Snell は Catalina の総合的なレビューを出版した。その題名は "macOS Catalina レビュー：新時代が見える、但し前方注意。"

勿論、新しい素晴らしいものを試すのが好きで、日常の仕事には使っていないテスト用の Mac があるのであれば、お好きな様に今直ぐ Catalina へアップグレードを！ それが我々の多くがやっていることで、Catalina へ行く途中で太平洋の嵐に巻き込まれても、覚悟は出来ているはずである。

討論に参加

tvOS 13 は登場したが、このアップデートは些細なもので、Home 画面上で新しい自動再生のビデオを目にすることなったり、或いは我々の読者が報告してきているバグに遭遇したりすることがない限り、それが走っているとは気づかない程度のものである。私は、今年初めに何が新しくなるかを "tvOS 13 を早速見てみる" (10 June 2019) で取り上げたが、興味深い新機能がベータサイクルの後期になって現れた：Picture in Picture (PiP) である。

ようやくである！iPad は何年も前から PiP を持っていたし、そして、それは Apple TV にあって当然の機能のようにも思えた。残念ながら、Apple は PiP を tvOS 13 で大きな制限付きで出荷した：それは Apple TV アプリの中でしか働かない。これ迄のベータでは、ビデオを Apple TV アプリの中で始めて、そのビデオを小さくして PiP にし、その上で、ビデオを小さな PiP ウィンドウの中で見ながら tvOS インターフェースの中をブラウズして回れた。きっと簡単にするためなのであろうが、出荷版の tvOS 13 では、Home 画面に戻ると、PiP で再生されているビデオは消えてしまう。

PiP を Apple TV アプリだけに限定することでその魅力は減じられるが、有用だと感じる人もいるかもしれない。PiP を能動化する手順を説明する：

1. Apple TV アプリの中でビデオの再生を始める。
2. Siri Remote のタッチパッドをタッチして (クリックではない！)、PiP ボタンが現れるようにする。(もし Remote アプリや Control Center のリモートを使うのであれば、ビデオを一時停止し、再開すれば PiP ボタンが現れる。)
   
3. スワイプアップしてボタンをハイライト、そしてタッチパッドをクリックする。(ボタンに到達するにはスワイプダウンするのではと思われるかもしれないが。その表示メニューは画面の底部ではなく頂部にある。)

ビデオは右下隅の PiP ウィンドウへと縮小する。PiP の制御子を出すには、TV ボタンを押す。隠すには、Menu を押す。隠すために、間違って TV ボタンを押さないように。何故ならば、そうすると Apple TV の Home 画面に戻ってしまう。

PiP ウィンドウには３つの制御子がある。

タッチパッドをスワイプして一つをハイライトし、クリックして能動化する：

• PiP ウィンドウを全画面にする： 左側のボタンをクリック。
• PiP ウィンドウを移動させる： 中央のボタンをクリックして PiP ウィンドウを右上隅に移動させる。再度クリックして、反時計方向次の隅に移動させる、等々。
• PiP ウィンドウを閉じる： 右側のボタンをクリック。

繰り返しになるが、Apple TV アプリでブラウズするために PiP 制御子から離れたい場合、Menu ボタンを押す、TV ボタンではない。

面白いのは、PiP で一つのビデオを再生しながら、別のビデオも全画面で再生し始められることである。ただ望みのビデオへとナビゲートして行き、通常通り再生するだけである。全画面ビデオの音声は通常通り再生されるが、PiP ビデオの方の音声は消される。

ビデオを入れ替えたり、PiP ウィンドウを閉じたりも出来る。前と同様 PiP 制御子を呼び出す。Siri Remote タッチパッドをタッチするか、ビデオを一時停止し再開するかのどちかをする。

今回の場合、２つのボタンが現れる：

• ビデオを入れ替える： 左側のボタンはビデオ間での入れ替えをさせてくれる。全画面ビデオを PiP ウィンドウに縮小し、そして前の PiP ビデオを全画面に拡大する。
• PiP ウィンドウを閉じる： 右側のボタンは PiP ウィンドウを閉じる。

PiP は Apple TV アプリ内でしか働かないことを考えると、私が思い浮かべられる主な使い方には、PiP ウィンドウでスポーツ試合の進行を追いながら、別の試合や他の番組を全画面で見るといったものがある。しかし、どんなアプリを使っている時でも PiP が使えるようにすれば、Apple は PiP をもっと有用なものに出来たのにと思わざるを得ない。

tvOS 13 の PiP に他の良い使い方がありますか？ 使うつもりはありますか？ コメントで教えて欲しい。

討論に参加

オペレーティングシステムをアップデートする際には、さまざまの目玉機能と並べて、Apple はいつも何らかの追加機能を忍び込ませてくれる。iOS 13 と iPadOS 13 で Apple は近くにある Wi-Fi ネットワークに接続するためのもう一つ新たな方法を追加したが、この新しい方法は従来あった最良の方法よりもさらにもっと素早く使えるものとなっている。

この新しい接続の選択肢が加わったことにより、全部で 4 通りの方法が提供されるようになった！ 全部を覚えるのは無理という方も、そのうちのどれかはあまり使いやすくないという方もおられるだろう。新しい 4 番目の方法は取り立てて大ニュースと言えるほどのものではないが、新たな Wi-Fi ネットワークに接続しなければならない必要がよくあるという方には、この方法を使う方が便利かもしれない。

私がこの新しい Wi-Fi 接続方法をたまたま見つけたのは、私の本 Connect and Secure Your iPhone and iPad を iOS 13 での数多くの変更点に合わせて、また iPadOS 13 で変わった点に合わせて徹底的に書き直し、さらにそれを 13.1 に合わせて更新する作業をしている最中だった。更新後のこの本にはこの記事で述べた Wi-Fi 接続のヒントも載っているし、それ以外にも何百もの新しい、あるいは改良された点が解説してある。例えば Safari に搭載された Apple の最新の追跡対策テクノロジーや、改訂された Find My サービスの使い方の説明も載っている。iPhone や iPad でネットワーキングやセキュリティに関して何か助けが必要なら、どうぞこの本を Take Control から入手して頂きたい。(本に載っていない疑問点がもしあれば、どうぞお気軽に私に尋ねて頂きたい！)

では、Wi-Fi ネットワークに接続するための 4 つの方法を、順々に見て行こう。最初は、最新の方法だ。

Control Center を使う

iOS 13 で、Apple は Control Center の機能を拡張して、利用可能な Wi-Fi ネットワークのリストにアクセスするための新たな方法を提供した。この新しいインターフェイスを使うには次のようにする：

1. スワイプして Control Center を開く。(iPad または iPhone X かそれ以降では、スクリーンの一番上から下向きにスワイプする。旧型の iPhone や iPod touch では、スクリーンの一番下から上向きにスワイプする。)
2. ネットワークプラターをタップしてそのまま押さえ続け、プラターを拡張する。
3. Wi-Fi ボタンをタップしてそのまま押さえ続け、ネットワークのリストを開く。
4. 参加したいネットワークをタップする。
5. 求められればパスワードを入力する。

一番下に見える Wi-Fi Settings をタップして Settings > Wi-Fi を開くこともできる。

この新しいオプションは世界を揺るがすほど重大なものではないけれども、間違いなく他の方法よりも簡単だし、とりわけデバイスのロックを外さずにロック画面から始めることができる点も見逃せない。

Settings アプリを使う

iOS の最も初期の時代以来、Settings アプリを通じて Wi-Fi ネットワークに接続することはいつもできていた：

1. Settings > Wi-Fi を開く。
2. Networks と書かれた下に並ぶネットワーク名のうちから一つをタップする。
3. 求められればパスワードを入力する。

もしも接続したいネットワークの名前が (“閉じて”いるか“隠れて”いるかして - これらは今や時代遅れの「見えないことによるセキュリティ」で、今もまだ使っている人たちがいる) 見えなければ、Other をタップしてからネットワーク名とパスワードを入力する。

この手順をもう少し自動化するために、項目 Ask to Join Networks を Ask または Notify に設定しておくことができる。どちらに設定しても、デバイスは既知の、保存されたネットワークに優先的に接続してくれる。けれども既知のネットワークが一つも利用可能でない場合には、Ask に設定してあれば別のネットワークに参加するようプロンプトが出るはずだ。(どのネットワークが表示されるかの基準を Apple は何も説明していない。) Notify に設定してあれば、すべてのネットワークのリストが出る。

一つかそれ以上のデバイスで Personal Hotspot 機能が有効になっていれば、Personal Hotspots ネットワークのリストも出る。それに加えて、iOS 13 では Popular Networks リストも表示されることがある。どうやら、近くにあるネットワークのうちどれに他の人たちが既に接続しているかを受動的にスキャンすることでそのリストを判定しているようだ。このやり方は少々侵略的な感じもするが、これはただ単に公共の送信情報を使っているだけだ。私自身はまだ Popular Networks リストが表示されるのを見たことがない。最新のオペレーティングシステムで Apple が箇条書きにしている点の一つだが、Apple はこれについて明確な説明を提供していない。

また、Apple は Auto-Join Hotspot も追加したが、これはいわゆる“フェイルオーバー”の方法だ。もし iOS 13 が既知の Wi-Fi ネットワークを見つけられなければ、Personal Hotspot を使って同じ iCloud アカウントにログイン中の iPhone またはセルラー iPad に接続する。他のデバイスで Personal Hotspot がオフになっていれば、それをオンにすることさえできる。(macOS 10.15 Catalina も同様のオプションを提供する。)

最後にもう一つヒントを述べておこう。Family Sharing が Personal Hotspot と統合できるようになった。もしあなたが Family Sharing グループのメンバーならば、Settings > Personal Hotspot > Family Sharing をタップしよう。その画面で Personal Hotspot 用の Family Sharing を有効にすれば、家族の全員が自動的にアクセスできるように設定することもできるし、あなたの許可を得てからアクセスできるようにもできる。家族で旅行する際にはこの機能が便利だろう。

連絡先を経由して参加する

iOS 12 以来、あなたの近くにいる人が連絡先にあなたを登録していて、かつあなたが参加したい Wi-Fi ネットワークのパスワードを持っていれば、あなたもそのネットワークに参加できる。例えば友人の家を訪問していて、その家のネットワークに接続したい場合などに便利な機能だ。ただし重要な点は、その友人があなたを登録している連絡先項目に、あなたが iCloud で使っている電子メールアドレスが含まれている必要があることだ。友人のパスワードを使うには次のようにする：

1. あなたのデバイスがその友人の iPhone、iPad、あるいは Mac の近くにあるようにする。この機能は Bluetooth と近接性に依存するからだ。.
2. 参加したいネットワークをタップする。.
3. その友人のデバイスに Wi-Fi Password のポップアップが開いて、説明の中にあなたが参加したいネットワークの名前とあなたの名前が表示される。その友人が Share Password をタップする必要がある。.
4. するとパスワードがセキュアに、しかも黙ってあなたのデバイスに送信され、あなたのデバイスは何のプロンプトも出さずにネットワークに接続する。.
5. その友人は Done をタップしてダイアログを閉じる。.

QR コードを使って参加する

iOS 11 の時点で、Apple は手間を最小限にしてネットワークの詳細を共有するための素敵にビジュアルな方法として、Camera アプリを使ってスキャンする QR コードを追加した。ホットスポットを共有するこのフォーマットはもともと Android の世界で開発されたもので、ネットワーク名とそのパスワードをエンコードしている。

Wi-Fi を有効にするための QR コードは、実際に世の中でそれほど一般的に使われている訳ではない。私はコーヒーショップや人の集まる場所で見たことはあるが、おそらく私と同じような QR Code の熱狂的支持者が使っていたものだろう。いくつかのカンファレンスでも、出席者たちがカンファレンスのネットワークに手軽に接続できるようにと用意されているのを見たことがある。また、一部の Wi-Fi ルータではデフォルトのネットワークパスワードを探したりせず手軽に初めての接続ができるように QR コードを使っている。

QR コードを使ってネットワークに参加するには、ただ単に iPhone か iPad のカメラをそれに向ければよい。(Settings > Camera > Scan QR Code がオンになっている必要があるが、デフォルトではオンだ。) あるいは、iOS 13 と iPadOS 13 で改善された Control Center で、QR コードのみを探すコントロールを使うこともできる。(Settings > Control Center > Customize Controls へ行き、QR Code Reader を追加する。)

Camera アプリで Wi-Fi ネットワークの QR コードをスキャンするには、次のようにする：

1. カメラをコードに向けて、コードの全体が画面に入るようにする。
2. iOS がコードを認識し、Wi-Fi QR Code 通知を出して "_ネットワーク名_" ネットワークに参加と表示する。その通知をタップする。
3. Join Network をタップする。

Control Center から Wi-Fi ネットワークの QR コードをスキャンするには：

1. スワイプして Control Center を開き、QR Code ボタンをタップする。
2. カメラをコードに向けて、コードの全体が QR Code 枠に入るようにする。
3. iOS が素敵なコード認識アニメーションを表示し、それが Wi-Fi 記号に姿を変えると、最後には Wi-Fi ネットワーク "ネットワーク名" に参加しますかというメッセージが開く。Join をタップする。

長らくくすぶり続けている QR Code 革命にあなたも参加して、あなたが使っている Wi-Fi ネットワークへのアクセスを提供する QR コードを作成したいなら、コードを生成するウェブサイトかアプリを使う必要がある。私がお薦めするのは QiFi サイトだ。ここは JavaScript を使って完全にあなたのブラウザの中だけでコードを作成し、あなたの認証情報をサーバへ送信したりしないからだ。それからまた、もしもあなたが本格的に QR コードに興味を持ってそれを作成するためのある程度の自動化を構築したいならば、Charles Edge がその話題で記事を書いている.のでご覧頂きたい。

一つ警告しておかなければならないことがある。その QR コードの中で Wi-Fi パスワードは暗号化されていない！ だから、そのような QR コードをオンラインにポストしたり、目の届かないところに置きっぱなしにしたりしてはいけない。けれども、公共ホットスポットやあなたの自宅の中などでは素晴らしく便利だ。私も自宅用に作ろうかと考えているところだ。

つい最近、Wi-Fi はその初代の 802.11b 規格と Wi-Fi の呼称がデビューしてからの 20 周年を祝ったばかりだ。また、Apple のマーケティング担当副社長 Phil Schiller が、Apple が初めて Wi-Fi を搭載した Mac である２枚貝型の iBook にビデオをストリーミングしつつ、エアマットの上に飛び降りることでワイヤレスネットワーキングの大飛躍を表現してみせて以来の 20 年目でもある。今では Wi-Fi ネットワークはどこにでもあるが、新たなネットワークに参加しようとなればまだまだある程度の摩擦が残っている。そのための選択肢が多くなれば、生活の中のほんのちょっとした部分が円滑になることだろう。

討論に参加

もしもあなたが Apple デバイスの一台を最近セットアップまたはリストアして、かつあなたの Apple ID で二要素認証を有効にしているならば、その設定の段階で Apple がどのようにデバイスのプライバシーとアカウントのセキュリティを維持しているかについて、あなたの理解を超える内容のメッセージを目にしたかもしれない。

そのメッセージは次のような感じのものだ。「あなたの Mac Password を入力してください。Mac "その Mac の名前" のロックを外すためにあなたが使っているパスワードを入力してください。このパスワードは、あなたの Apple ID、保存されたパスワード、および iCloud に保存された他のデータを保護します。あなたのパスワードは暗号化されており、Apple がそれを読むことはできません。」これの代わりに、あなたの iPhone や iPad のパスコードを求めるプロンプトが出るかもしれない。

これは何とも、矛盾していて、分かりにくく、明らかに間違っているのではないか？ いったいなぜ Apple は、今使っているデバイスでなくて、あなたが持っている別のデバイスのパスワードなりパスコードなりを尋ねるのか？ ひょっとするとこれは詐欺か何かではないのか？ 具体的には何が起こっているのか？

Take Control 出版者の Joe Kissell もこの問題に遭遇したのだが、私もまた、長年出版し続けている私のネットワーキングとセキュリティの本 Connect and Secure Your iPhone and iPad を iOS 13 と iPadOS 13 用に改訂する作業をしていて、この問題に遭遇した。(私の本は今回のリリースでタイトルが短くなり、内容は既に iOS 13.1 に合わせて更新済みだ。iOS のネットワーキング、プライバシー、セキュリティについて知りたい方は、どうぞお読み頂きたい。)

このプロンプトが出たという話を私は去年一度だけ聞いたことがあったが、私自身は今回より以前には一度も目にしたことがなかった。でも、これを自分の目で見た以上、Apple の資料書類を検討して欠けた部分を推定することで、今は何が起こっているのか把握できている。簡単に要約を言えば、このプロンプトは実際に Apple があなたのセキュリティを保護するために働いていることを示しているのであって、Apple の説明は正確に事実を述べている。ただ、何が起こっているかを十分に詳しく述べているとは言えない。(詳しく述べれば数画面分のテキストが必要だろう。) では、これから特ダネをお話ししよう。

iCloud はあなたのためにセキュア化データを二種類に分けて保存する

あなたのデバイス同士の間で iCloud を経由して同期されるデータはすべて、(通常は HTTPS を使って) 転送される間も、また Apple のサーバ上に留まっている間も、ずっと暗号化されている。あなたが iCloud.com 経由でそれにアクセスする場合には、その一部が復号化されて読めるようになる。その復号化されたデータについては、そのデータが留まっている間それを保護するための暗号化鍵を Apple が持っており、仮に Apple が法執行機関から強制されればそのデータを引き渡すことも可能となる。

Apple はどのデータが Apple の所有する暗号化鍵と共に保存されているかを公開している。非常に稀な状況下で、誰かが不正侵入で Apple の鍵を手に入れるか、あるいはサーバのセキュリティを破るかすれば、その iCloud.com 経由でアクセスする情報が伝送途中で、あるいは iCloud から、抜き出されてしまうかもしれない。極めて可能性は低いが、完全に不可能ではない。

このデータはまた、もしもフィッシング攻撃が成功すれば危険に晒されることになり得る。フィッシングが成立するためには、攻撃者が誰かを騙して、その人が自分の認証情報を正当なサイトに入力していると思い込ませ、それが実は攻撃の中間者であるという状況を作り出しさえすればよい。フィッシング攻撃にはさまざまの種類のものがあるが、中でも深刻なものの一つは、不正に発行された HTTPS 証明書を入手することで正当かつセキュアなサイトの見せ掛けをすべて手に入れるというやり方だ。

そうするとその攻撃者はただ単にあなたのログイン名とパスワードを使って iCloud へのログインを試みることもできるし、さらには要求して二要素認証のために使う追加のログイントークンを Apple に送らせることさえできる。もしあなたがそのトークンをフィッシングサイトで入力すれば、その後は攻撃者が iCloud でそれを使えるようになる。

もちろん、Apple ユーザーたちもフィッシングの被害に遭ってきた。ただ、私の知る限り、Apple が不正な証明書の攻撃に悩まされたことはない。数年前に、Google のサイトへの訪問者の一部がこのやり方でフィッシングされたことが複数回あった。それ以後、証明書の発行手続きや追跡手続き、および書類が正当に発行されたものであるか否かを各ブラウザが確認する方法が改善されて、この特定の攻撃のリスクは大幅に減ったが、完全に取り去られた訳ではない。

フィッシングのリスクが存在することにより、Apple は同社が高度にセキュアであるべき、あるいは高度にプライベートだと見なすデータを、エンドツーエンド (終端間) の暗号化で保護する道を選んだ。エンドツーエンドの暗号化ならば、同期されるデータの内容について Apple の側から何も知ることができなくなる。Apple のサーバを通り過ぎるデータの暗号を解くために必要な鍵を Apple は持っていない。その代わりに、それらの鍵はあなたの個々の iPhone、iPad、Mac にのみ存在している。

Apple の“iCloud のセキュリティの概要”ページに、エンドツーエンドで暗号化されるサービスのフルリストが載っているが、そこには iCloud Keychain、Screen Time 情報、Health データ、Wi-Fi パスワード、Photos の People アルバム、それに新しい Find Me サービスのクラウドソーシングによる位置情報が含まれる。これ以外にも、デバイスとデバイスの間のやり取りを円滑に進めるための他の種類のデータもあると思われる。

その結果として、今挙げた種類のデータをあなたが iCloud.com で見ることはできず、これらのデータにはあなたのデバイスを使う必要がある。基本的に、iCloud は自らが転送するデータの内容について一切何も知識を持たない同期サービスとして挙動する。たとえ Apple がこれらの情報を開示するようにと政府から要求されたとしても、Apple としては解読できない暗号データを提出するしかない。そのようにデザインされているのだ。(このやり方は Apple がさらにもっと機密を要するデータ、たとえばクレジットカード番号、パスコード、指紋または顔認証の情報などを保存するやり方とは異なっている。そちらの情報は iPhone、iPad、および T2 チップ装備の Mac に搭載された Secure Enclave の中に保存される。そのデータは決して Secure Enclave を出ることがなく、データの大部分はこのチップの中に既に一方通行の暗号化で不可逆的に変換された状態で保存されている。)

Apple の iCloud 同期システムは公開鍵暗号化法に依存している。これは互いにリンクされた２つの鍵、公開鍵と秘密鍵を使う。公開鍵は自由に共有され、秘密鍵所有者のための何かを暗号化したい誰もがその公開鍵を使い、その秘密鍵がそのデータを解読する。iCloud Keychain やそれと同種の機密データについて、Apple はあなたのデバイスに命じて公開鍵と秘密鍵を作って保存させ、iCloud を通じて同期される情報のやり取りを開始させる。そのデバイスは秘密鍵を外へ出すことは決してせず、iCloud アカウントに連結されたすべての他のデバイスの公開鍵を保管する。

このようにして保護されたデータは個々のパッケージとして保存される。例えば URL とアカウント名とパスワードが一つのユニットにまとめられて保存される。そして、それぞれのユニットがランダムなメタデータによって識別される。このメタデータは個々のデータパッケージに固有の ID として以外には何の意味も持たない。一人のユーザーの同期セットに属するすべてのデバイスは、新規に登録されたハードウェアも含めて、互いにメタデータ情報を交換することによって同期する。例えば、たった今あなたがあるウェブサイトへのログインを Mac 上で作成したばかりで、あなたの iPhone 上にはその情報がなかったとしよう。するとその Mac はそのログイン情報をその iPhone の公開鍵を使って暗号化し、それが iCloud 同期を経由して iPhone に送られ、その秘密鍵で解読される。このやり方は典型的であると同時に、合理的だ。

困難なのは秘密裏にデータを同期するところではない。そうではなくて、新たなデバイスをこのセットの中へと追加したい場合に、困難が起こる。それがどのように働くのかを理解するために、あなたの iCloud パスワードが果たす役割を理解しておく必要がある。

傍受からの保護のための追加の要素

Apple の iOS 12 セキュリティ白書がこのシステムをある程度深く説明していて、あなたの iCloud Apple ID アカウントパスワードそれ自体が新規デバイスの登録に使用されることもあると述べている。それは、聞いた印象ほどには心配すべきことでない。Apple はあなたのパスワードを知らないからだ。その代わりに、Apple は暗号化された形でのパスワードを保存している。あなたがパスワードを入力する度に、膨大な量の数学演算を使用する一方通行の暗号化法によって暗号化される。(この処理は「ハッシュ法」と呼ばれている。) これにより、元のパスワードを知ることは事実上不可能となる。(このやり方は Secure Enclave に保存されるデータ、例えばパスコードなどにも使われる、)

あなたが iCloud Security Code を "out-of-band" 要素と設定することもできる。そうすると、それが他のデータと同じ手段で転送されることがなくなる。この "out-of-band" 要素は、決してオンラインに置かれることのない秘密を要求することでデータの乗っ取りを阻止するために一般的に使われるやり方だ。この場合には、一つのデバイスの上であなたが作成するか、または Apple があなたのために作成するかし、あなたが別のデバイスの上でそれを入力することになる。

(iCloud Security Code なんて聞いたこともないという方のために言い添えれば、そう思うのはあなただけではない！ この言葉は Apple のサイトにさえほとんど載っておらず、Apple の白書もこのコードについて深く議論していない。私は何年も前にこの言葉を使った記憶があるが、TidBITS 出版者の Adam Engst はこの記事の編集作業をするより前にはこの言葉を一度も聞いたことがないと言っていた。)

でも、iCloud パスワードにも、iCloud Security Code のやり方にも、一つの欠陥がある。私は、これこそが Apple があなたの同期セットの中の他のデバイスのパスワードやパスコードを尋ねるようになった理由なのではないかと思う。iCloud Security Code もまた、もう一つ新たに覚えて取り組むべき情報であり、従って簡素さに向けた Apple の誓約に反するものとなる。それにまたこれは、Apple がエンドツーエンドでセキュア化し iCloud 経由で同期するデータセットが iCloud Keychain のみであった時代に生まれ、二段階認証も、それを引き継いだ二要素認証も、いずれもまだ Apple ID 用に使われていなかった時代のものであった。だから、現在の Apple のセキュリティと認証のための要件を満たせる程度に堅固なものではないかもしれない。

iCloud パスワードについて言えば、こちらにはまた違った種類の懸念がある。Apple はあなたの iCloud パスワードを知らないけれども、iCloud.com にあなたがログインする度に、暗号化されたパスワードが Apple に送られ、それをハッシュ計算にかけて保存された値と照合するまでの間、そこに留まっている。けれども (これもまた可能性は低いとは言っても) そのパスワードが転送途中に、あるいはフィッシングされて、あるいはなんらかの方法で盗まれて、捕獲されてしまうのもあり得ないことではない。当然ながら Apple もそのことは考えていて、こう考えるだろう： パスワードが傍受される可能性はあり得るのだから、Apple としてはあたかも傍受が毎日のように起こっているかのような心構えで傍受に対する防御をしなければならない、と。

いくつかの会社は、ハッシュ化されたパスワードさえ転送する必要がない方法へ移行しようと試みた。例えば AgileBits は 1Password.com を最新のブラウザベースの暗号化アルゴリズムに基づいて構築した。暗号化されないパスワードもデータも決して AgileBits に保存されず、ブラウザへ送られることもない。その代わりに、ブラウザ自体が必要なすべての暗号化作業を担当し、暗号化されたデータを AgileBits へ送る。ログイン後、1Password.com のサーバは暗号化されたパッケージのみをユーザーのブラウザへ送り、ブラウザは暗号化鍵をローカルにのみ、しかもそのセッションが継続している間のみ保存する。

Apple は iCloud.com でこの方法に移行することをしていないので、盗まれたりフィッシングに遭ったりする可能性のある iCloud パスワードに依存する代わりに、デバイスごとのパスコード/パスワードのシステムへと移行した。まだ Apple はこの新しいやり方を文書化していないが、それだからこそこの記事ではその動作の仕方についてこれ以上詳しく書くことができない。ユーザーがスクリーン上で目にするテキストのどれ一つとして、まだ Apple のサポートサイトやマーケティングサイトに登場していないし、さきほど紹介した白書にも、他のどこにもこのことについて触れられていない。でも私は過去に読者たちからこれについて聞いたことがあり、Take Control 出版者の Joe Kissell は最近新しいデバイスをセットアップしながら彼自身の目で見た。そして私も、ついに今回 iPhone を iOS 13 にアップグレードした後でこれを目にした。

私が判断できる限りで述べれば、この新しいシステムは次のように働く：

1. セットアップ中のデバイスであなたは Apple ID でログインし、第二要素のログインを確認する。(パスワードのみの Apple ID アカウントではこの種のダイアログは出ないようだが、Apple はそのようなアカウントを作らないようにと強く勧めている。)
2. iCloud 同期セットに属する少なくとも 1 台のデバイスの上で、Apple はそのデバイスのパスコードまたはパスワードを暗号化したものを共有される情報に追加する。その情報のうち Apple が読めるものはデバイスの種類とデバイスの名前だけだ。
3. Apple はその情報を iCloud に同期し、その後で新しいデバイスのセットアップ過程がその情報を取り込み、プロンプトを出してあなたにパスコードかパスワードを入力するよう求める。
4. あなたが正しいパスコードかパスワードを入力すれば、そのデバイスはそのパスコード/パスワードのデータをセットから削除し、その代わりに暗号化の新しい公開鍵と秘密鍵を生成して、その後は他のデバイスと同様にその２つの鍵に依存して動作する。こうしてこの新しいデバイスは信用されたデバイスのセットの一員となり、エンドツーエンドで暗号化された iCloud データを同期できるようになる。

セットに属するすべてのデバイスの共有鍵の暗号化されたパスコードとパスワードを Apple が保持していることも考えられる。けれども、それをすれば一つの継続的なリスクが生まれることになる。秘密を獲得した誰かがさらなるアクセスを得てしまうことも考えられるからだ。

この過程が示すものは何かと推測すれば、それは Apple がデバイスのパスコードやパスワードを見たり処理したり保存したりすることが決してなく、セキュアな転送以外にパスコードやパスワードを引き渡すことも決してないということだ。Apple が要求するのは、デバイスから初めて iCloud にログインする段階での手続きの一環として、あなたの Apple ID アカウント名とパスワードが HTTPS を使って送られることだけであり、それ以後の段階では要求しない。

全体的に見て、この新しいやり方は理にかなっていてセキュアなものに思える。Apple はぜひともこれを説明するサポート書類を提供して、何が起こっているかについてユーザーたちに安心を与えて欲しいものだと思う。また、Apple がセキュリティ白書を iOS 13 用に更新する際に、徹底的な詳細を記してくれることを願いたい。

討論に参加