中宣部防沉迷实名认证系统接入-JAVA版
2月24和25日下午，中宣部出版局主办的网络游戏防沉迷实名认证系统企业接入培训会在线上召开。其中提到，在2021年5月31日前，所有游戏企业需完成在运营游戏的防沉迷系统的接入工作。6月1日起，未接入防沉迷系统运营游戏要停止运营。
相信最近一段时间，所有游戏公司、发行企业、渠道平台应该都收到了上面这条消息。 相关的技术同学估计也已经开始或者准备接入该系统了。
U8SDK作为手游聚合SDK提供商，在之前我们已经推出了统一的防沉迷插件，所有使用U8SDK对接渠道平台的游戏，都不需要处理实名认证和防沉迷逻辑。目前我们也第一时间对该防沉迷实名认证系统进行了研究，并已完成技术对接。所以，对于使用U8SDK的游戏，在完成工具升级之后，即可和之前一样无差别使用。
由于该系统刚刚推出， 网络上关于该系统的技术对接相关的分享还没有， 我们这里先分享一下我们接入过程中遇到的问题，方便大家快速接入。
接入之前， 您需要先在该系统注册:网络游戏防沉迷实名认证系统， 注册完成后， 可以在系统中-》技术支持-》文档中心下载最新的《网络游戏防沉迷实名认证系统接口对接技术规范》文档。 该文档中就有需要接入的API的详细说明和相关技术规范。建议技术接入之前， 大家可以先仔细阅读一下该文档。
简单概括
1、该系统只提供了实名认证、实名认证查询以及数据上报（玩家上线和下线操作）三个API接口；
2、上面三个API都是对应的http/https 的api，没有可以直接接入的SDK。 所以，如果游戏客户端或者SDK中没有实名认证界面，那也是需要自己制作实名认证UI界面的。（如果使用U8SDK的话， 只需要打包客户端中将防沉迷插件打入即可）；
3、接入该系统，只能验证和查询用户的身份信息，并不能自动完成防沉迷逻辑。 所以，如果你游戏客户端或者SDK中没有实现防沉迷逻辑，那么还是需要根据实名认证的结果，对未成年人做游戏时长和消费限制等逻辑。（如果使用U8SDK的话， 只需要打包客户端中将防沉迷插件打入即可）。
接入补充说明
关于三个API的接入， 文档中基本已经说得很详细了。 可能有疑问的地方，当属数据加密算法和签名生成算法。所以这里，我们对文档中不清楚的地方，做了以下补充说明：
1、数据加密算法
游戏运营单位调用网络游戏防沉迷实名认证系统开放接口时，为确保数据安全，需要对所有请求报文体进行加密传输。网络游戏防沉迷实名认证系统会为接入的游戏运营单位发放访问密钥secretKey，游戏运营单位在调用接口时，需要使用该密钥对请求报文体数据进行AES-128/GCM + BASE64算法加密。
文档中，对于数据加密算法， 仅仅一笔带过。 只是说了数据加密使用AES-128/GCM + BASE64算法。 但是我们稍微研究之后即发现：AES-128/GCM算法有多种变体，各种变体的实现细节都不同；Base64算法也有很多变体。 所以文档这里对于加密算法，建议还是需要给一个详细的代码样例。 不过好在该系统后台有人工工单，解答还是很及时的。 这里我们贴一下该算法的相关细节：
1、AES-128/GCM 算法中IV长度使用的是12位，IV值的内容，每次可以随机；
2、对数据加密后， 最终Base64前的加密数据是：IV值+加密数据 （+是连接符）;
3、算法具体使用的是AES/GCM/PKCS5Padding，而不是AES/GCM/NoPadding；
4、加密使用的是分配的SecretKey，但是使用该Key加密之前，需要先将该Key转为16进制的bytes
5、Base64使用的是java.util.Base64（RFC 4648版本）
数据加密算法片段（java版）如下：
public static String encrypt(String content, String key) {
try {
byte[] hexStr = HexUtils.decodeHex(key.toCharArray());
//加密算法：AES/GCM/PKCS5Padding
Cipher cipher = Cipher.getInstance("AES/GCM/PKCS5Padding");
SecretKeySpec skeySpec = new SecretKeySpec(hexStr, "AES");
//随机生成iv 12位
byte[] iv = new byte[12];
secureRandom.nextBytes(iv);
//数据加密， AES-GCM-128
cipher.init(Cipher.ENCRYPT_MODE, skeySpec, new GCMParameterSpec(128, iv));
byte[] encrypted = cipher.doFinal(content.getBytes()); //数据加密
//iv+加密数据 拼接 iv在前，加密数据在后
ByteBuffer byteBuffer = ByteBuffer.allocate(iv.length + encrypted.length);
byteBuffer.put(iv);
byteBuffer.put(encrypted);
byte[] cipherMessage = byteBuffer.array();
//转换为Base64 Base64算法有多种变体， 这里使用的是java.util.Base64
return java.util.Base64.getEncoder().encodeToString(cipherMessage);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
2、签名算法
1、 将除去 sign 的系统参数和除去请求体外的业务参数，根据参数的 key 进行
字典排序，并按照 Key-Value 的格式拼接成一个字符串。将请求体中的参数
拼接在字符串最后。
2、 将 secretKey 拼接在步骤 1 获得字符串最前面，得到待加密字符串。
3、 使用 SHA256 算法对待加密字符串进行计算，得到数据签名。
4、 将得到的数据签名赋值给系统参数 sign。
文档中对于签名算法的描述，还是挺详细的。 根据文档中的步骤，我们不难实现数据签名算法：
public static String sign(String appID, String bizID, String time, String secretKey, Map<String, String> data, String encryptData) {
Map<String, String> params = new HashMap<>();
params.put("appId", appID);
params.put("bizId", bizID);
params.put("timestamps", time);
if(data != null && data.size() > 0) {
for(String key : data.keySet()) {
params.put(key, data.get(key));
}
}
String signStr = generateUrlSortedParamString(params, false);
signStr = secretKey + signStr + encryptData;
String sign = EncryptUtils.sha256(signStr);
Log.d("NPPARealNameHandler generate sign str:%s; sign:%s", signStr, sign);
return sign;
}
唯一需要注意的是，对于查询实名认证接口API， 是GET请求， 直接携带ai参数。 签名的时候， ai参数作为业务参数， 而不是加密参数。 所以该协议没有数据需要加密。也就是上面签名接口中，将数据传入到data中作为业务参数参与签名，而不是加密后的encryptData数据。
用例测试
该系统后台提供了一个接口测试页面， 我们实现好接口后，可以在该测试界面中，下载测试用例文档。 用测试用例文档中的数据和测试URL进行接口测试。
中宣部接口测试UI.png
需要测试的时候，我们可以先在这个界面对应用例上面点击开始测试， 然后会生成该用例的测试码（有效时间1小时）。然后将测试码拼接到对应用例的测试URL后面，就可以开始对应接口的测试了。
如果使用的是U8SDK， 我们在U8Server后台-》全局设置中，做了一个实名认证自助测试界面。方便你接入该系统时，快速完成接口的测试。
第一次接入防沉迷实名认证系统， 是必须完成所有用例的测试的。 所以你可以在U8Server后台自助测试界面中，很方便地完成每个用例的测试。如果需要看具体演示，你可以百度搜U8SDK进入官网查看哈。
U8SDK实名认证自助测试
上面界面中， 先在防沉迷实名认证系统中对应测试用例中点击开始测试，获取测试码。 然后在U8SDK后台自助测试界面该用例后面点击“立即测试”，在弹出的界面中，输入测试码，点击测试即可完成测试。
好了， 以上就是我们分享的防沉迷实名认证系统接入的技术点了。
