あなたがAndroidの開発をフォローしているのであれば、ここ数年の間にかなりの「Verified Boot」という名前を聞いたことがあるはずです。 Googleは、Android 4.4（Kitkat）のセキュリティ機能を徹底的に邪魔にならない方法で導入し、Androidオペレーティングシステムの新しいリリースで徐々にその認知度を高めています。
ここ数日の間に、Googleが世界で最も使用されているモバイルOSの最新版に「 厳密に強化された検証済みブート 」が存在するというニュースがありました。 Android Nougatは、デバイスの起動時に、より高いレベルのセキュリティチェックを使用します。 Marshmallowでは、Verified Bootはユーザーに警告を出すだけでしたが、システムパーティションに問題があることが検出された場合に備えて、Android Nougatはそれをさらに一歩進め、Googleが「Strictly Enforced Verified Boot」と呼んでいるものを使用します。パーティションの異常、ブートローダへの変更、またはデバイス内の「悪意のある」コードの存在を検出した場合に備えて、デバイスの起動を一切許可しないでください。 これは疑問を投げかける：「これは正確にはユーザーにとって何を意味するのですか？」、Androidユーザーの2つの主なカテゴリー（カジュアルユーザーとパワーユーザー）で答えが異なります。 。
厳密に検証された検証済みブート
まず、検証済みブートの背景：Androidがパーティションに対して検証テストを実行する場合、通常、パーティションを4KiBのブロックに分割し、それらを署名付きテーブルと照合することによって実行します。 すべてがうまくいったら、それはシステムが完全にクリーンであることを意味します。 しかし、いくつかのブロックが改ざんされている、または破損していることが判明した場合、Androidは問題についてユーザーに通知し、それを解決するかどうかはユーザーに任せます。
AndroidのNougat、およびStrictly Enforced Verified Bootを使用して変更しようとしています。 検証済みブートが強制モードで実行されている場合、パーティション内の障害は許容されません 。 問題が検出された場合は、デバイスの起動 が許可されず、ユーザーがセーフモード環境で起動して問題の解決を試みる可能性があります。 ただし、厳密に検証された検証済みブートは、単なる不良データブロックに対するチェックではありません。 通常、データブロック内のエラーも修正できます。 これは、データブロック内の誤りを訂正するために使用することができる前方誤り訂正符号の存在によって可能になる。 しかし、これは必ずしもうまくいくとは限らず、うまくいかない場合には、あなたは水中でかなり死んでいます。
厳密に検証された検証済みブート：良い、悪い、醜い
1.良い
Androidデバイスで検証起動を強制すると、デバイスのセキュリティが強化されます。 デバイスがマルウェアに感染した場合、Strictly Enforced Verified Bootは次にデバイスを起動したときにそれを検出し、それを修正するか、またはおそらく何かをするように促します。
この機能はデータの破損もチェックし 、ほとんどの場合、FECコードのおかげで、データに導入されたエラーを修正することができます。 Googleは、 1つの不明なビットエラーを255ビットで訂正できるFECコードを使用しています 。 確かに、それはかなり小さい数のように思えますが、モバイル機器に関して、それを全体的に見てみましょう：
注：以下の値は、Android開発者に関するGoogleのエンジニアSami Tolvanenによるブログ投稿から取得されたものです。
GoogleはRS（255, 223）FECコードを使用することができた。これらのコードは255ビットで16個の未知のビットエラーを訂正することができただろうが、32ビットの冗長データによるスペースオーバーヘッドは15％近くになるだろう。そしてそれは、特にモバイル機器ではたくさんあります。 Androidが4〜8 GBのメモリを搭載した予算の大きいスマートフォンではOSが主流であり、15％の追加スペースが確かにたくさんあるように思われるという事実にそれを付け加えてください。
スペースを節約するために、エラー訂正機能を犠牲にすることで、GoogleはRS（255, 253）FECコードを使用することにしました。 これらのコードは、255ビットの未知のエラーを1つだけ訂正できますが、スペースのオーバーヘッドはわずか0.8％です。
注： RS（255、N）はリードソロモン符号の表現で、誤り訂正符号の一種です。
悪い
「コインには2つの側面があります」と聞いたことがありますか？ もちろんあります。 Strictly Enforced Verified Bootに対するGoogleの意図は、赤ちゃんのユニコーンとしての純粋さには間違いありませんが、それらには独自の問題があります。
Strictly Enforced Verified Boot がマルウェアをチェックするとき、カーネル、ブートローダ、その他私があなたを悩ませないようなものへの違法な変更もチェックしますが、これはAndroid Nougatがおそらく応援で多くの問題に遭遇することを意味します。 Verified Bootは、不要なマルウェアコードとブートローダのロックを解除したコードを区別できないため、カスタムROMを点滅させます。 つまり、デバイスにロックされたブートローダが付属していて、OEMがブートローダのロック解除を許可していない場合は、ほとんど不可能です。 うまくいけば、誰かがこれの悪用を考え出すでしょう。
ありがたいことに、自分のデバイスを根付かせ、追加された機能のためにカスタムROMをフラッシュするほとんどの人は、Nexusのような開発者に優しい携帯電話を使っています。 このトピックに関して考慮すべきことはたくさんあります。少なくともカスタムROMの終わりではありません。少なくとも、ロック解除されたブートローダが付属しているデバイス、またはブートローダをロック解除できるデバイスではそうです。 しかし、Samsungの携帯電話のようなデバイスでは、ブートローダのロック解除が正式に許可されていません。これらのデバイスでは、ブートローダのロック解除は、間違いなくVerified Bootによる「問題」として認識されます。
Strictly Enforced Verified Bootで発生するもう1つの問題は、root権限の取得やカスタムROMのインストールにあまり関心がないユーザーにも影響することです。 時間が経つにつれて、あなたがあなたのデバイスを使用するにつれて、メモリ内の自然なデータ破壊が起こることは間違いありません。 マルウェアの存在によるものではなく、単にそれが起こるからです。 これは通常問題ではありません、または少なくとも確認されたブートがそれに変わるほど深刻な問題ではありません。 Strictly Enforced Verified Bootが起動時に修正できない破損したデータがある場合、それはあなたのデバイスの起動を許可しません。 私の意見では、これはユーザーパーティション上のデータが壊れていることよりも大きく、目に見える問題です。
3.醜い
Verified Bootを強制することのすべての利点、およびすべての潜在的な問題、おそらく最も厄介なのは、OEMが意図したとおりにAndroidを使用できないようにデバイスをロックするためにこれを悪用し始めることです。オープンで、開発者にやさしい、そして完全にカスタマイズ可能です。 厳密に検証された検証済みブートはOEMの手に渡り、人々が自分のデバイス上でブートローダのロックを解除できないことを保証し、それによってカスタムROMやXposedモジュールのような機能強化ツールをインストールすることを禁止します。
Android Nougat：Androidが機能する方法の根本的な変化？
Googleの意図は、デバイスがマルウェアの影響を受けている場合、またはメモリにデータブロックが破損している場合に何をすべきかわからない、カジュアルなAndroidユーザーに対する潜在的な問題の回避だけであると確信しています。そして製造業者はユーザーが彼らが提供されたもので生活することを制限するための完璧なツールであり、それ以上は何もない。
もちろん、だれかがこの状況の悪用、または回避策を見つけ出すでしょう、そして私たちはAndroidの真の精神の中で、彼らがそうすることをちょっと望んでいます。 しかし、誰かが解決策を見つけ出すまで、ユーザーができることは、開発者に優しいメーカーからデバイスを購入することだけです。
メインのイメージ提供：Flickr
