如何在复杂业务场景中优雅实现Android指纹验证?

2,413 阅读12分钟
原文链接: www.jianshu.com

前言

目前指纹领域无论从产品角度还是技术角度都已经趋于成熟,但是当各位开发者准备深入探究的时候,却发现网上很多文章都是皮毛,很难有较深的启示。本文将着重介绍指纹验证开发整个过程,包括技术选型、产品的设计方案逻辑、代码的架构以及后续测试中遇到的兼容性问题等几个方面。在这里抛砖引玉,希望能给予大家一些启发。

技术选型

产品:咱们 Android 端能做指纹验证吗?
开发:不能,一堆兼容问题。
产品:咱们 Android 端能做指纹验证吗?
开发:不能,一堆兼容问题。
产品:咱们 Android 端能做指纹验证吗?
开发:不能,一堆兼容问题。
产品:咱们 Android 端能做指纹验证吗?
开发:我……我试试吧……

着手调研,开发前肯定先拿市面上竞品的功能来瞧瞧。我们同比了支付宝、微信支付和招商App。

产品:怎么支付宝和微信就没兼容问题了?

开发:那是因为支付宝和腾迅有自己的协议!(一听怎么XXX支持,怎么XXX没问题,升起无名火)这个标准直接和设备厂商合作,而应用方只有微信和支付宝自己。支付宝指纹支付标准是 IFAA ,腾讯的指纹支付标准是 SOTER,也就是说没有其他应用方会使用这个标准。所以很看应用方和设备厂商的协商程度。现在 IFAA 没有开源,只有 SOTER 是开源的了,如果接入,我们能省去兼容性测试的工作量,而且有些 6.0 以下的机型 SOTER 也支持。还有!(星星眼)每个指纹将会有唯一 ID,也就是说,我们能把账号和指纹绑定起来,更加安全。

产品:不行不行!这 SOTER 压根没支持华为,华为用户是我们的主要用户群,而且以后机型的扩展受第三方支持的限制。

开发:之前小米和华为就没有支持 SOTER 标准,现在小米是支持了,华为不见得会支持,因为 SOTER 和厂商合作,出厂的时候就将私钥存储在 TEE 中,华为目前多 TEE 系统开发尚未成熟,只能支持一个 TEE ,显然华为不愿意将唯一的 TEE 交给腾讯掌控。其他手机厂商一般使用高通或第三方的 TEE 系统方案,这些系统目前都支持多 TEE 运行环境,即使将其中一个 TEE 的公共密钥交给腾讯运营,并不影响手机厂商运营自己的 TEE 平台。

产品:不接入了,我们用 Google API。

开发:那好,来制定下条件先:

  1. 设备硬件不支持直接没得玩
  2. 手机要有除了指纹外的安全认证方式(比如密码、图案) ,这是安卓系统的双重锁规则。
  3. 用户手机至少录入了一个指纹,没录入指纹说明平时没有用过指纹验证功能,这种用户我们就不管了。
  4. 使用 Google API,不管什么情况,只要验证的指纹是系统指纹列表里存在的,就验证通过,Google API 是没有提供指纹唯一ID的,所以想要根据本机上的指纹索引来区别不同手指无法做到,也就无法实现指纹和账号绑定。
  5. 仅支持 Android 6.0 以上系统,Google 官方支持指纹识别的标准接口是在 Android6.0 开始的,如果厂商在这之前就已经做了指纹识别,那我们就不管了。(开发者也可以使用厂商提供的第三方指纹识别SDK)

产品:(点头)可以,开干吧!用 Google API 兼容性问题处理和测试量较大,所以我们支持的机型做成可配置,控制风险。第一期先支持几个机型。

架构

好了,demo 写完了,看下了产品文档。啥?场景这么复杂?!分支繁多,还需要结合到之前存在的手势验证功能(用户有两种安全方式可选:指纹验证和手势验证)。

业务场景有四个:

  1. 冷启动app的指纹验证
  2. 切换账号登陆后的引导设置
  3. 在设置页用户手动开启指纹登陆
  4. 设置页手动关闭指纹登陆

每一次验证的状态,都会通过 AuthenticationCallback 回调,我们可以理解为是指纹验证的生命周期。

public class MyAuthCallback extends FingerprintManagerCompat.AuthenticationCallback {

        @Override
        public void onAuthenticationSucceeded(FingerprintManagerCompat.AuthenticationResult result) {
            super.onAuthenticationSucceeded(result);
        }

        @Override
        public void onAuthenticationError(int errMsgId, CharSequence errString) {
            //验证过程中遇到不可恢复的错误
            super.onAuthenticationError(errMsgId, errString);
        }

        @Override
        public void onAuthenticationFailed() {
            super.onAuthenticationFailed();
        }

        @Override
        public void onAuthenticationHelp(int helpMsgId, CharSequence helpString) {
            //验证过程中遇到可恢复错误
            super.onAuthenticationHelp(helpMsgId, helpString);
        }
    }

onAuthenticationSucceeded 和 onAuthenticationError 的回调意味着本次的认证结束,会根据当前所处业务场景给予用户不同的引导。

而 onAuthenticationFailed 和 onAuthenticationHelp 的情况,四个业务场景都是一样的,都是在界面上提示用户,我们可以合并一起处理。

所以我们根本不需要一个业务场景就对应一个 AuthenticationCallback 回调类,我们可以只用一个 AuthenticationCallback 回调类来根据当前所处的业务场景分发行为。但是我又不想在 onAuthenticationSucceeded 和 onAuthenticationError 的回调中有 Switch 逻辑。所以对于四个场景各不相同的 onAuthenticationSucceeded 和 onAuthenticationError 的回调方法,我们用状态模式来分离,这样把与特定状态相关的行为局部化,并且将不同场景下的行为分割开来。(需要给用户什么提示,什么操作,包括验证次数超限的处理,取决于当前所处的场景状态)

另外一点:需要在运行时刻根据状态来改变行为,比如说用户从一个正常态,转移到验证过程异常或者验证过程被劫持的状态。

验证过程异常情况,也即是说,受用户 root 或自定制情况,通过测试的同一个机型有可能验证过程异常。

验证过程被劫持,因为 Google API 只返回 true 或 false,我们当然不能无条件相信这个验证结果,所以需要在应用内产生一对非对称的密钥,保证验证过程不会被篡改。如果拿到验证结果解密失败,就进入了被劫持的状态了。

验证过程异常和验证被劫持的状态基本处理一致,都是属于用户无法再继续验证的场景,我们可以把这两个状态合为一。按照开发的思路,有异常,被劫持,那肯定是失败了,是吧? 但是按照产品的思路,其他 3 个业务场景按失败处理,但如果是关闭指纹的场景下(4. 设置页手动关闭指纹登陆),就算是失败了,也要让他去关闭成功,不然可能会出现用户手机中途 root 或极端情况下,无法关闭指纹,从而引起客诉。

按照分析我们可以发现,被劫持和验证过程异常的情况的处理,依赖于当时所处的场景,所以呢,我们无法把被劫持和验证过程异常当做一个独立的状态了。只能抽出作为一个公共方法。

绿色底为 Activity 层,白色底为 Util 层

为了不和业务逻辑耦合在一起,工具类包装了一层,主要封装了验证条件的判断,指纹类的初始化等等,最主要的是封装了加密类 CryptoObjectCreatorHelper ,我们考虑到安全因素,如果不加密的话,就意味着App 无条件信任认证的结果,这个过程可能被攻击,数据可以被篡改,这是 App 在这种情况下必须承担的风险。但是这个加密过程和业务是无关的,我们不想让 Activity 层感知到,所以密钥和加密对象的销毁,会统一由工具类来把控。

为了安全,每次验证过程的密钥都不同,验证过程一结束,也就是回调 onAuthenticationSucceeded 和 onAuthenticationError 时,都需要销毁掉密钥,但是我们不想让业务层来操作,所以工具类也有自己的一个 AuthenticationCallback ,在 AuthenticationCallback 里做一些和业务无关的操作,再回调 Activity 的 AuthenticationCallbackListener 。

工具类的 CallBack 是 FingerprintManagerCompat.AuthenticationCallback 实现类,业务层的 AuthenticationCallbackListener 是自定义接口,因为不想把和业务无关的往上传递,比如说,验证成功的 AuthenticationResult ,验证错误的 typeId,这些业务并不关心。Activity 的 AuthenticationCallbackListener 会把请求统一转发给控制器 FingerPrintTypeController,在转发给控制器的前后,我们可以做一些通用的业务操作,比如说停止界面的扫描动画,发一些异步的请求等等,这个就是代理模式的应用了。

那控制器 FingerPrintTypeController 和四个场景的关系又是如何?我们看看类图。

可以看到,四个场景,对应四个状态类,控制器和状态类实现了同一个接口,在内部根据当前场景转发给对应的类, 那怎么根据场景转发给对应类?我们建立一个映射表,把场景和类对应起来。每次匹配的话只要 O(1) 复杂度。

 private interface FingerPrintType {
        void onAuthenticationSucceeded();

        void onAuthenticationError(String content);
    }

 private class LoginAuthType implements FingerPrintType {
        @Override
        public void onAuthenticationSucceeded() { }

        @Override
        public void onAuthenticationError(String content) { }
    }

    private class ClearType implements FingerPrintType {
        @Override
        public void onAuthenticationSucceeded() { }

        @Override
        public void onAuthenticationError(String content) { }
    }

    private class LoginSettingType implements FingerPrintType {
       @Override
        public void onAuthenticationSucceeded() { }

        @Override
        public void onAuthenticationError(String content) { }
    }

    private class SettingType implements FingerPrintType {
        @Override
        public void onAuthenticationSucceeded() { }

        @Override
        public void onAuthenticationError(String content) { }
    }

    private class FingerPrintTypeController implements FingerPrintType {
        private Map<String, FingerPrintType> typeMappingMap = new HashMap<>();

        public FingerPrintTypeController() {
            typeMappingMap.put(GESTURE_FINGER_SETTING, new SettingType());
            typeMappingMap.put(GESTURE_FINGER_LOGIN_SETTING, new LoginSettingType());
            typeMappingMap.put(GESTURE_FINGER_CLEAR, new ClearType());
            typeMappingMap.put(GESTURE_FINGER_LOGIN, new LoginAuthType());
        }

        @Override
        public void onAuthenticationSucceeded() {
            typeMappingMap.get(mType).onAuthenticationSucceeded();
        }

        @Override
        public void onAuthenticationError(String content) {
            typeMappingMap.get(mType).onAuthenticationError(content);
        }
    }

这个时候产品又说了,同样是异常情况,但是被劫持和异常过程异常的提示文案要不一样,ok,那我们将提示语和操作分离开来,提示和业务场景的对应关系也预先缓存在 Map 里,直接 get 获取具体提示,作为参数传入就可以了。

      //普通异常情况提示
        exceptionTipsMappingMap = new HashMap<>();
        exceptionTipsMappingMap.put(GESTURE_FINGER_SETTING, getString(R.string.fingerprint_no_support_fingerprint_gesture));
        exceptionTipsMappingMap.put(GESTURE_FINGER_LOGIN_SETTING, getString(R.string.fingerprint_no_support_fingerprint_gesture));
        exceptionTipsMappingMap.put(GESTURE_FINGER_CLEAR, null);
        exceptionTipsMappingMap.put(GESTURE_FINGER_LOGIN, getString(R.string.fingerprint_no_support_fingerprint_account));

兼容问题

1. 明明符合条件,isHardwareDetected() 返回 false?

在同一机型上调用 FingerprintManagerCompat 的 isHardwareDetected() 和 hasEnrolledFingerprints() 时候,返回的都是 false,但是调用 FingerprintManager 的 isHardwareDetected() 和 hasEnrolledFingerprints() 时,却是返回 true。

解决:是否符合指纹条件可以多加一层判断。

2. Letv X500 Android 6.0,API23 不按正常的套路回调

onAuthenticationError 和 onAuthenticationFailed,理论上应该是识别失败的情况,但是该机型点击取消指纹识别也会先回调一次Error,如果遇到这种情况,只能根据具体项目环境中去进行规避适配了。

3. 魅族上遇到的坑

onAuthenticationHelp 回调不按套路出牌,正常官网文档解释,这个方法的回调时机是在指纹认证期间发生可恢复性的错误时回调。结果在魅族上,启动指纹识别认证的时候就会回调这个方法,里面传递回来的信息提示是“等待按下手指”,也就是说,它的 onAuthenticationHelp 回调跟官网时机不一样,而且方法的作用也变了,它在正常的情况回调了 onAuthenticationHelp。

解决:不影响验证流程,无需解决

4. 小米 锁屏和切后台生命周期不一致

产品需求:用户锁屏或切到后台时(onStop)自动停止指纹验证,回到界面时(onResume)自动调起验证。

所以我在指纹回调方法中加入了标志位 isInAuth。onStop时保存 isInAuth,onResume时 isInAuth == true 则自动调起验证。

        @Override
        public void onAuthenticationSucceeded(FingerprintManagerCompat.AuthenticationResult result) {
            isInAuth = false;
        }

        @Override
        public void onAuthenticationError(int errMsgId, CharSequence errString) {
            isInAuth = false;
        }

        @Override
        public void onAuthenticationFailed() {
            isInAuth = true;
        }

        @Override
        public void onAuthenticationHelp(int helpMsgId, CharSequence helpString) {
            isInAuth = true;
        }

然而小米6、米mix2 锁屏时的生命周期是 onAuthenticationError -> onStop;切到后台是 onStop -> onAuthenticationError。导致不同流程下拿到 isInAuth 标志位不一致,无法自动调起验证。

解决:界面指纹按钮可以手动调起验证,无需兼容处理。

小米5生命周期同上,但是无论是自动还是手动调起验证,马上就回调了 onAuthenticationError,也就是说 MI5 从后台切回来后,指纹验证流程中断。

解决:用一个栈来存储调用方法顺序,如果验证方法调起,马上就回调 onAuthenticationError 方法,则判定是属于兼容问题,按验证失败来解决。

5. 密钥解密失败

三星SM-A9100 、Nexus 6P密钥解密失败
解决:暂无法解决

其他兼容解决方案:

  • 三星passSdk(不过从2018下半年开始,Pass SDK 将不再提供 DEVICE_FINGERPRINT_UNIQUE_ID 。也就是不再为每个已注册的指纹提供索引了。因此将无法通过 SDK 区分使用哪个指纹来验证用户。)
  • 魅族 flyme开发平台提供了指纹验证官方api

非兼容问题

1. 新注册指纹密钥解密失败

系统中注册了一个新的指纹的情况下,即使指纹在系统指纹列表里,验证也不通过。
解决:删除了当前无效的key,然后根据参数再次生成密钥。

 @Override
        public void onAuthenticationSucceeded(FingerprintManagerCompat.AuthenticationResult result) {
            ...
            /**
             * doFinal方法会检查结果是不是会拦截或者篡改过,
             * 如果是的话会抛出一个异常,异常的时候都将认证当做是失败来处理
             */
            try {
                result.getCryptoObject().getCipher().doFinal();
                mCustomCallback.onAuthenticationSucceeded(true);
            } catch (IllegalBlockSizeException e) {
                //如果是新录入的指纹,会抛出该异常,需要重新生成密钥对重新验证,这里加个次数限制,避免进入验证异常->重新验证->又验证异常的死循环
                if (happenCount == 0) {
                    beginAuthenticate();
                    happenCount++;
                    return;
                }
                mCustomCallback.onAuthenticationSucceeded(false);
            } catch (Exception e) {
                mCustomCallback.onAuthenticationSucceeded(false);
            }
           ...
        }

本文完整 Demo 地址
Demo 仅供参考架构和兼容处理,如果后续接入魅族和三星 SDK,可以考虑用策略模式替换Goolge API。