ローカル認証フローの合理化

ローカル認証フローの合理化

認証にフォーカスしたLocalAuthentication APIで、ユーザデータのプライバシーやセキュリティが保護される仕組みをご確認ください。LocalAuthenticationが、App内のシークレット、キー、他の機密リソースへのアクセスを許可する仕組み、複雑さを軽減する仕組み、Touch IDやFace IDなどの一般的なローカル認証方法のセキュリティやユーザビリティに依存する仕組みについて解説します。

リソース
ダウンロード

♪ ♪
こんにちは Security Engineering and Architectureチームのエンジニアの Felix Aceroですこのビデオでは LocalAuthenticationフレームワークを使用して認証機能を向上させる方法をお伝えします Appの認証と認可のフローを改善できますまず認証と認可の一般的な概念を見ていきますどのように Appに適用されるかです次に既存の LocalAuthentication API 特にLAContextがどのように認証スキームの実装に役立つかを確認しますそして最後に今年LocalAuthenticationに追加する新しいAPIが認証コードを効率化するためどのように役立つかを見ていきます
ではまず認証と認可について説明します認証と認可は別のものですが密接に関連するセキュリティの概念です認証はユーザーの身元を確認する行為です認可とはあるユーザが具体的なリソースに対して特定の操作を実行できるかを検証することですまとめるとどのようなリソースや操作が利用できるかを評価する前にまずユーザーが本人であることを確認する必要があるので認証は認可を可能にしますこの概念を説明するために具体的な例を見てみましょう Appで管理される一般的なセキュリティリソースの具体例を見てみましょう
セキュアエンクレーブキーは特定デバイスにバインドされメインプロセッサから分離されたベースのキーマネージャによって保護される特殊なキーの一種ですこれらのキーが特別なのはセキュアエンクレーブに秘密鍵を保存する際実際にキーを扱うことはなくそのキーで操作を実行するよう指示することですセキュアエンクレーブキーはアクセス制御と関連付けできます ACLと略されますアクセス制御は特定の操作を実行するため Blobの署名や復号化など特定操作のため要件を指定します
例えばデバイスのロック解除後など特定のアイテムを利用できるタイミングの指定特定操作実行の許可のため必要な認証要件の指定この例では Appがキーの署名と復号の操作を生体認証で保護しさらにキーはデバイスのロックの解除後のみ利用できるようにしたいとしますではこのキーに関わる署名操作の認証フローはどのようになるか見てみましょう
まずAppは署名のリクエストを発行する
Appがキーにアクセスできることを確認後システムは署名操作のための認証要件を特定するために処理を進めますこの場合署名の操作には現在登録されているユーザーから生体認証に成功することが必要ですその後システムは標準UIを介して生体認証プロセスをユーザーに説明します認証に成功するとシステムは残りすべての認証要件が満たされていることを確認し最後に署名操作を行い署名されたBlobを Appに返します
このフローに含まれる主な構成要素を確認することができますまずリソースですセキュアエンクレーブキーです次にキーで実行できる操作をします 3番目にこの要件には操作の実行が許可される人物とその人物の身元を確認するために使用されるべき認証手段が規定されていますこの例のパラメータを定義に当てはめると認証の場合ユーザーが正しいかどうか生体認証で答えることになります一方認可の場合は秘密鍵を用いた署名操作が許可されるかの問いにアクセス制御リスト指定された要件を確認することで回答しますこれがどのようなものであるかは現在の LocalAuthenticationの APIを使って実装することができるかを見てみましょう LAContextが提供する機能を簡単に確認してみましょうこれはフレームワークの中核の一つです LAContextはユーザーを評価するために使用されます生体認証やパスコードが必要な時の操作を行いますセキュアエンクレーブとのインターフェースにより生体認証情報の安全な管理も可能ですこの観点から LAContextは認証ケースをサポートするために使用することができます LAContext は他のフレームワークと連携し認可フローをサポートすることもできます例えばアクセスコントロールリストの評価に使用することができますもっと詳しく見てみましょうまず秘密鍵に関連する ACLにアクセスする必要があります安全なフレームワークが提供する SecItemCopyMatching APIの助けを借りて行えますクエリ内でReturnAttributes キーの提供を確認してください
アクセス制御リストがアクセス権を取得すると LAContextとevaluate AccessControl APIで直接評価することができるようになりますこの方法の最大の利点はユーザーに認証を求めるタイミングと場所を App内で決められることですこの場合アクセス制御リストが署名操作のために生体認証を要求しているので LAContextは FaceID または TouchIDのUIを表示します
ACLが LAContext内で認可されるとキーへの参照を得るためクエリの一部として使用できるようになりますこれは LAContextを UseAuthenticationContext キーの下で SecItemクエリに追加します
LAContextを秘密鍵の参照にバインドすることで署名の操作を実行しても別の認証の発生は保証し不要なプロンプトを出さずに操作を継続できますこれらのバインディングは LAContextが無効になるまで今後の署名に追加ユーザーインタラクションは必要ない
LAContextは非常に柔軟性が高く認可フローに関わる各ステップやパラメータを制御することができますまたセキュリティフレームワークなど他と組合せての使用も可能で幅広いユースケースに対応しますこの汎用性の代償としてコードがより複雑になります複数フレームワークが提供するAPIを注意深く調和特にキーシークレットコンテキストアクセス制御リストへの低レベルのアクセスが必要とする Appの場合 LAContextは最適なツールになりますしかしコンテンツや機密性の高いリソースへのアクセスを許可する方法だけが必要な場合はこの柔軟性と引き換えによりシンプルなAPIを使用することができます最後のトピックは Appの効率化です iOS16とmacOS13の新機能で LocalAuthenticationが導入されますより高度な認証に特化したAPIです新しいAPIは LocalAuthenticationの既存の概念の上に構築され一般的な認証フローの実装を簡素化することを目的としています Appの中核にエネルギーを集中させます新しいAPIで導入された重要な抽象化はLARightです
LARightの最も単純な使用例は Appで定義されたリソースの承認例えばAppの「ユーザープロファイル」セクションへのアクセスを制限するためにまずユーザーが生体認証に成功することが必要です
デフォルトでは使用するデバイスに応じて TouchID FaceID Apple Watch またはパスコードを使い認証できる一連の認証要件によって権利が保護されます
また自分の権利と関連付けるより詳細な要件が必要です認証手段をさらに制限することができますそれでは LARightsの使い方を見てみましょう
まず最初にするべきことは権利のインスタンス化です必要条件を指定して実行しますこの場合ログイン権にはバイオメトリクスの使用またはデバイスのパスコードの入力が必要です次にユーザーがログイン権を取得できることを確認しますこの情報をもとにログイン操作を継続できるか Appの公開セクションにリダイレクトを判断するため使用されます最後に実際のアクセス認可に進むことができますローカライズされた理由を提供することでユーザーに見えるようになります
このように権利を認可すると全く新しいシステムドリブンなUIが表示されます UIはAppのウィンドウ内にレンダリングされ操作の由来や目的を理解してもらうために関連情報を提供しますこの新しいデザインによりよりシームレスに統合された承認フローを作成することが可能になると確信していますそれはユーザーにより多くの背景と情報を提供します
ここまで権利の作成と認可の方法について見てきましたではそのライフサイクルを詳しく見てみましょう権利のライフサイクルは未知の状態です Appが許可のリクエストを発行すると同時に権利の状態が認可に変更しますこの時点でユーザーには前のスライドで見た認可のUIが表示されます
操作の成否により権利の状態は「許可する」または「許可しない」に遷移する Appにとって最も重要な状態遷移です最後に権利は「許可する」状態から「許可しない」状態へも移行できます Appが権利の認証解除要求を発行したときインスタンスが割り当て解除されたときに発生します
認可された状態を維持するために必ず権利の参照を強くしてください
権利の認可が解除された後 Appは認可要求を発行してサイクルを再開することができます LARightインスタンスへのアクセス権を持っている場合その状態のプロパティを直接問い合わせられます KVOやCombineを使い状態遷移の観察できますまた Appで複数の権利を扱いますデフォルトの NotificationCenterに発行される didBecomeAuthorizedと didBecomeUnauthorizedの通知があり権利の状態を一箇所で観察することができます認証状態の変化が検出された後に発行されます
次に進む前にこの例題に戻りましょうログインの認証を解除してみましょうこうすることで次回のログイン時に新たな認証が必要なことを保証しています
権利のインスタンスを使い操作の認可方法を見ました Appで定義されたリソースの操作を許可しますまたこれらの権利のライフサイクルと状態が最終的にランタイムとどう結びついているかを見てきましたつまり Appのすべてのセッションで権利を正しく設定する必要があるどのように権利を持続させることができるかどのような可能性があるかを見ていきましょう
LARightsは RightStoreを利用して永続化できます
永続化される場合権利はアクセス制御リスト(ACL)で保護されたセキュアエンクレーブキーでバックアップされます権限要件に一致するアクセス制御リストまたはACで保護この方法は権利が永続化された後も認可要件が不変であることを保証することに役立ちます
また権利をバックアップする秘密鍵にアクセスできますそれを使って復号署名キー交換などの保護された暗号化操作を行う
対応する公開キーにもアクセス可能です暗号化署名検証などの操作を行うことができますこれは公開キーなので関連するバイトを
秘密鍵の操作のみ可能で権利の認証成功後に許可されますこれに対して公開鍵の操作は常に許可されています
権利を永続化するとき単一の不変の秘密も一緒に保存する機会がありますまた秘密は権利の認可要件に合致するアクセス制御リストと関連付けられ権利が認可された後にのみアクセス可能になります
要約すると LAPersistedRightsは RightStoreの支援によって作成される一度だけ設定されますその認証要件は不変ですこれらは保存されるため Appの異なるセッションにまたがって使用することができます内部的には特定のデバイスにバインドされ一意のセキュアエンクレーブキーに支えられそのキーを使用して権利の認証状態に応じて異なる暗号化操作を実行するため使用することができます最後にこれらの技術は単一の不変の秘密を保護するために使用することができます権利に関連する機能を理解したところでプレゼンテーションの冒頭で説明した署名操作を許可するシナリオの実装にどのように役立つかを見てみましょう正規権利をインスタンス化し認可要件の指定から始めるこの場合権利が発生した時点で生体認証が登録されているユーザーに対してのみ権利が発生するようにしたいと思いますそこでバイオメトリックスカレントセットの要件を利用
Right Storeから一意な識別子を提供する権利を永続化することができますこの識別子はAppの将来のセッションで権利を取得する必要があるときに役に立つことでしょう
権利が永続化されると公開鍵にすぐにアクセスでき明示的な認証を必要とせずに保護されていない操作を実行できるようになりますこの例では単純に公開バイトをエクスポートします
この後署名操作を行うときストアから権利を取得することができます作成時に指定した一意の識別子でを使っています次に現在のユーザーを認証することができます権利の認可操作を実行しますこの時点でシステムは認証プロセスを実行します要件が満たされていることを確認します
権利の認証が完了したらその秘密鍵を使用できます保護された暗号化操作を行うためにこの場合Appのサーバーが発行するチャレンジに署名するために秘密鍵を使用します最後に認証と認可の一般的な概念の間に存在する関係特に認証が認可をどのように可能にするかをお話しました LAContextが提供する機能の一部と安全なフレームワークがどのように組み合わせるか説明しました強力で拡張性の高い認証フローを実現しましたそして最後に新しく追加されたLARightが特定の認可のユースケースを実装するためにどのようにコードの効率化を図れるかを調べました AppでLocal Authenticationの使用時に説明したいくつかの機能がユーザーのプライバシーとセキュリティを保護しながらコードを簡素化することに役立つかを御検討くださいありがとうございました

4:58 - LAContext (authorize a signature operation 1)

let query: [String: Any] = [
    kSecClass as String: kSecClassKey,
    kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave,
    kSecAttrApplicationTag as String: "com.example.app.key",
    kSecReturnAttributes as String: true,
]

var item: CFTypeRef? = nil
guard SecItemCopyMatching(query as CFDictionary, &item) == errSecSuccess, let attrs = item as? NSDictionary, let accessControl = attrs[kSecAttrAccessControl] else {
    throw .aclNotFound
}

5:15 - LAContext (authorize a signature operation 2)

let context = LAContext()
try await context.evaluateAccessControl(accessControl as! SecAccessControl, 
                      operation: .useKeySign, 
                       localizedReason: "Authentication is required to proceed")

5:44 - LAContext (authorize a signature operation 3)

let query: [String: Any] = [
    kSecClass as String: kSecClassKey,
    kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave,
    kSecAttrApplicationTag as String: "com.example.app.key",
    kSecReturnRef as String: true,
    kSecUseAuthenticationContext as String: context
]

var item: CFTypeRef? = nil
guard SecItemCopyMatching(query as CFDictionary, &item) == errSecSuccess, item != nil else { 
    throw .keyNotFound
}

6:00 - LAContext (authorize a signature operation 4)

let privateKey = item as! SecKey

var error: Unmanaged<CFError>?
guard let sgt = SecKeyCreateSignature(privateKey, self.algorithm, blob, &error) as Data? else {
    throw .signatureFailure
}

8:28 - LA Right (basic usage)

// LARight: Basic usage

func login() async {
   self.loginRight = LARight(requirement: .biometry(fallback: .devicePasscode))
   do {
       try await loginRight.checkCanAuthorize()
   } catch {
       navigateTo(section: .public)
       return
   }
   do {
      try await self.loginRight.authorize(localizedReason: self.localizedReason)
 navigateTo(section: .protected)
   } catch {
      showError(.authenticationRequired)
   }
}

11:01 - LARight (logout and deauthorization)

// LARight: Basic usage

func login() async {
   self.loginRight = LARight(requirement: .biometry(fallback: .devicePasscode))
   // ...
   do {
       try await self.loginRight.authorize(localizedReason: self.localizedReason)
  navigateTo(section: .protected)
   } catch {
       showError(.authenticationRequired)
   }
}

func logout() async {   
   await self.loginRight.deauthorize()
}

13:44 - LAPersistedRight

// LAPersistedRight: Retrieval and private key usage

func generateClientKeys() async throws -> Data {
    let login2FA = LARight(requirement: .biometryCurrentSet)
    let persisted2FA = try await LARightStore.shared.saveRight(login2FA, identifier: "2fa")
    return try await persisted2FA.key.publicKey.bytes
}

func signChallenge(_ challenge: Data, algorithm: SecKeyAlgorithm) async throws -> Data {
    let persisted2FA = try await LARightStore.shared.right(forIdentifier: "2fa")
    let localizedReason = "Biometric authentication is required to proceed"
    try await persisted2FA.authorize(localizedReason: localizedReason)
    return try await persisted2FA.key.sign(challenge, algorithm: algorithm)
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース