上周排查一个Java服务的密钥加载问题日志里抛的是NoSuchAlgorithmException。当时我第一反应是算法拼错了可代码里明明写的是“AES”。顺着异常栈追到源头才发现密钥是从数据库里读出来的字符串而写入时同事用了new String(keyBytes)读出来之后再按 UTF-8 转回字节数组二进制内容早就变了。这种问题在 Java/Android 项目里太典型了尤其是当团队习惯把密钥当普通文本扔进数据库、配置文件的时候。这篇就聊聊怎么把一个数据库里的字符串安全、正确地还原成可用的 AES 密钥以及整个过程里那些容易踩得防不胜防的坑。1. 为什么AES密钥会以字符串形式出现在数据库里1.1 密钥的本质一段随机字节不是文字AES 密钥不是“一串字符”而是一段随机字节。以 128 位 AES 密钥为例它是 16 个byte每个 byte 的取值是 0 到 255。这里面有大量不可打印、不可见甚至会被字符集解释成控制符的值比如0x00、0xFF、0x8F。这些字节在二进制世界里很干净但只要试图把它当成文本来处理问题就来了。数据库的普通列类型VARCHAR、TEXT是按“字符”存储的底层会按照数据库默认的字符集通常是 UTF-8把字节解释成字符串。二进制数据一旦进入这种列等于把一份 PNG 图片丢进记事本再保存——数据被“翻译”坏了。所以把 AES 密钥塞进VARCHAR列之前必须先用一种“二进制安全”的编码方式把字节转换成由可见字符组成的字符串。这也是标题里“数据库里读出来的字符串”这个现象的根源。更直接一点说如果表结构允许密钥应该放在BLOB、VARBINARY这类二进制列里根本不需要转成字符串。但现实是很多业务表早就建好了开发不愿意加列或者要兼容多个数据库方言于是大家默契地选择把密钥编码成字符串。这个选择本身没错错的是编码方式。1.2 常见的三种存储形态以及背后的风险实际项目里AES 密钥转成字符串后落在数据库里基本逃不出三种形态。第一种是 Base64。用Base64.getEncoder().encodeToString(keyBytes)把原始字节编码成由 A-Z、a-z、0-9、 和 / 组成的字符串末尾可能有填充。这种方式体积增加约 1/316 字节的密钥会变成 24 个字符但这种膨胀换来了可靠的二进制安全而且 Java 标准库直接支持不用引第三方包。第二种是 Hex也叫十六进制字符串。每个字节用两个十六进制字符表示比如E8A5B8这种。可读性比 Base64 强但体积翻倍而且大小写、是否带0x前缀都可能造成问题。第三种是最糟糕的直接用new String(keyBytes)甚至String.valueOf(keyBytes)把字节数组转字符串然后存进数据库。这种操作强依赖 JVM 默认字符集绝大多数情况下会在转换过程中改变字节内容还原时要么报错要么加密和解密对不上。这里有一个很重要的结论从数据库读出来的字符串能不能还原成原来那个密钥取决于当初写入时用的是哪种编码方式。如果写的时候就是 Base64那么读出来之后 Base64 解码就能还原如果写的时候是new String且不是 ISO-8859-1 这类等宽字符集转换而来那原始数据基本已经损坏还原不了。2. 还原密钥前的关键准备搞清编码方式2.1 Base64最常用的传输编码但也有版本差异Base64 在 Java 生态里有好几种实现。Java 8 之前的项目常用sun.misc.BASE64Decoder或Apache Commons Codec这在老项目里依然存在。Java 8 之后官方推荐使用java.util.Base64。把数据库字符串还原成密钥标准流程是String storedKey getKeyFromDatabase(); // 从数据库读出来 byte[] keyBytes Base64.getDecoder().decode(storedKey.trim()); SecretKey aesKey new SecretKeySpec(keyBytes, AES);storedKey.trim()这一步很多人会漏。数据库读出来的字符串有可能带前导空格、换行也可能是 SQL 拼接时把空白带了进去。Base64 解码器遇到空格和换行通常会抛IllegalArgumentException但 trim 一下能省掉这个坑。另外一个容易被忽略的差异是MIME变体。有些系统存储 Base64 时使用了带换行的格式比如每 76 个字符插一个\n这是邮件传输的惯例。如果用Base64.getDecoder()去解默认是不支持换行的会直接抛异常。如果确认数据是这种格式可以改用Base64.getMimeDecoder()它允许忽略这些换行符号。不过在实际的密钥场景里密钥长度最长也就 44 个字符256 位密钥 Base64 后是 44 字符基本没有换行需求所以看到换行时反而要怀疑是不是数据格式有问题。2.2 Hex可读性强但必须统一格式如果你拿到的是 Hex 字符串还原思路也明确每两个十六进制字符转换成一个byte。Java 17 开始提供了HexFormat这个方法很简洁byte[] keyBytes HexFormat.of().parseHex(storedKey.trim());但很多 Android 项目还停留在 Java 11 甚至 Java 8这时候要么引第三方库要么自己写一个简单的解析方法。下面这个实现足够应付密钥场景public static byte[] hexToBytes(String hex) { if (hex null || hex.length() % 2 ! 0) { throw new IllegalArgumentException(Invalid hex string length); } byte[] result new byte[hex.length() / 2]; for (int i 0; i result.length; i) { int high Character.digit(hex.charAt(i * 2), 16); int low Character.digit(hex.charAt(i * 2 1), 16); if (high 0 || low 0) { throw new IllegalArgumentException(Invalid hex char); } result[i] (byte) ((high 4) low); } return result; }用的时候要确认几件事字符串里是否带了0x前缀有的系统会写成0xE8A5B8解析前要去掉大小写是否统一十六进制A-F大小写不影响解析但如果你在字符级别直接校验就得注意了数据库字段长度是否足够32 字节的 AES-256 密钥Hex 后是 64 个字符如果字段只有 50 个字符密钥早就在写入时被截断了。2.3 当初用了 new String(keyBytes) 怎么办几乎每周都能看到有人写出类似这样的代码String sk new String(secretKey.getEncoded(), UTF-8);然后存进数据库。这种做法的本质是把一个 0 到 255 的字节序列按照 UTF-8 的规则映射成 Unicode 字符。UTF-8 是变长编码0 到 127 的 ASCII 范围会一对一映射但 128 到 255 的字节会被解释成多字节序列的一部分导致一个字节可能变成两个或三个字符。这个映射不可逆或者说还原后字节长度会变几乎不可能恢复。如果当初强制用了ISO-8859-1也叫 Latin-1那还有救。ISO-8859-1 是单字节编码0-255 每个字节都映射到对应字符所以字符串.getBytes(ISO-8859-1)可以精确还原原始字节。如果用了 UTF-8 或项目默认的 UTF-8那基本确定要重新生成密钥。遇到这种情况我建议不要花时间“抢救”直接在代码里生成新密钥然后用正确的 Base64 方式重新存储同时把用到旧密钥的密文数据一并迁移。3. 实操把数据库字符串还原成AES密钥3.1 标准还原流程Base64版假设你的数据库里存的是 Base64 编码的密钥字符串下面是一个完整的还原方法包含了必要的校验public static SecretKey restoreKeyFromBase64(String storedKey) { if (storedKey null || storedKey.trim().isEmpty()) { throw new IllegalArgumentException(Stored key is empty); } byte[] keyBytes Base64.getDecoder().decode(storedKey.trim()); if (keyBytes.length ! 16 keyBytes.length ! 24 keyBytes.length ! 32) { throw new IllegalArgumentException(AES key length must be 16, 24 or 32 bytes, but got keyBytes.length); } return new SecretKeySpec(keyBytes, AES); }方法先做空值判断再做 Base64 解码然后校验长度。很多人在这一步省掉了长度校验理由是new SecretKeySpec也不会检查长度。但正因为它不检查Cipher初始化时才会抛出InvalidKeyException异常堆栈里带着“Wrong key size”这样的信息排查时要从栈底翻到栈顶浪费不少时间。提前校验至少能快速锁定是存储的原始数据不对还是算法配置不对。如果是从ResultSet里读取注意 JDBC 驱动可能返回String类型的对象也可能返回Clob取决于数据库驱动和列类型。绝大多数场景下rs.getString(secret_key)就行了但如果列类型是CLOB需要额外处理成字符串否则可能拿到的是java.sql.Clob对象而不是文本内容。3.2 标准还原流程Hex版如果你确认数据库里的密钥字符串是 Hex 格式可以调用之前写的hexToBytes方法public static SecretKey restoreKeyFromHex(String storedHexKey) { String normalized storedHexKey.trim(); if (normalized.startsWith(0x) || normalized.startsWith(0X)) { normalized normalized.substring(2); } byte[] keyBytes hexToBytes(normalized); if (keyBytes.length ! 16 keyBytes.length ! 24 keyBytes.length ! 32) { throw new IllegalArgumentException(AES key length must be 16, 24 or 32 bytes, but got keyBytes.length); } return new SecretKeySpec(keyBytes, AES); }注意去掉0x前缀这步我是放进还原函数里了。很多从 Python 项目转过来的同事习惯把密钥写成0x开头的十六进制字符串存到 Java 的数据库里后忘了这点导致解析的时候第一个字符x直接报错。3.3 校验还原结果不要直接拿去加解密拿到SecretKey后别急着往业务代码里塞。先写一个自检方法用固定明文和固定 IV 做一次加解密确保密钥没有被意外篡改。以 AES/GCM 为例GCM 模式自带完整性校验比较适合做这种验证public static boolean verifyKey(SecretKey key) throws Exception { byte[] plain AES-KEY-VERIFY.getBytes(StandardCharsets.UTF_8); byte[] iv new byte[12]; // GCM 推荐 12 字节 IV Cipher cipher Cipher.getInstance(AES/GCM/NoPadding); cipher.init(Cipher.ENCRYPT_MODE, key, new GCMParameterSpec(128, iv)); byte[] ciphertext cipher.doFinal(plain); Cipher decryptCipher Cipher.getInstance(AES/GCM/NoPadding); decryptCipher.init(Cipher.DECRYPT_MODE, key, new GCMParameterSpec(128, iv)); byte[] decrypted decryptCipher.doFinal(ciphertext); return Arrays.equals(plain, decrypted); }这个方法很适合在服务启动的时候做一次“密钥健康检查”。我在某项目里曾遇到一个问题密钥字符串本身没有错但数据库里存的是用旧算法生成的一串字符长度和 Base64 都对只是解密后的字节排列和预期不一致。加一个自检方法后每次启动都会先断言一次密钥真实可用不用等凌晨批处理跑起来才被数据错误打醒。4. 真正容易踩的坑字符集、填充与密钥规范4.1 字符集的坑getBytes() 的默认编码问题String.getBytes()无参版本是很多 AES 密钥事故的源头。它会使用 JVM 的默认字符集而不同机器、不同环境、不同版本的 JDK默认字符集可能都不一样。在 Linux 服务器上通常是 UTF-8在 Windows 上可能是 GBK这就导致同一段代码在不同环境运行时字节转换结果不同。我之前排查过一个跨环境密钥不一致的问题开发机器是 Windows数据库里存下的密钥字符串是 GBK 编码的字节测试环境跑在 Linux启动时用 UTF-8 去还原结果密钥差了几个字节。最后加解密全部因为BadPaddingException失败。所以所有涉及字节和字符串转换的地方都应当显式指定字符集或者不使用字符集转换而使用 Base64、Hex 这类二进制安全编码。new String(keyBytes, UTF-8)这种写法已经够难搞了更糟的是有些人会把SecretKeySpec对象直接丢给toString()然后存库。得到的是类似javax.crypto.spec.SecretKeySpec182decdb的字符串这种字符串连长度校验都过不了更不要说还原成密钥。这类问题在代码 review 时就应该抓出来。4.2 填充模式与密钥长度的隐形约束AES 是分组密码按 16 字节一块处理数据。为了让任意长度的明文都能加密需要指定填充模式。常见的组合是AES/CBC/PKCS5Padding和AES/GCM/NoPadding。密钥还原本身与填充模式无关但使用密钥时很多人写Cipher.getInstance(AES)让底层自己去选模式和填充。这在大多数 Java 环境中默认是AES/ECB/PKCS5Padding虽然能用但 ECB 模式在安全性上有明显缺陷而且不同 JDK 提供方可能默认实现不完全一样。真正的坑在后面如果你存入数据库的密文是用AES/CBC/PKCS5Padding加密的而在还原密钥后用AES/ECB/PKCS5Padding解密解出来的数据大概率是乱码或直接抛异常。另一个隐含约束是密钥长度。AES 支持 128 位16 字节、192 位24 字节、256 位32 字节。Java 8 早期版本默认只支持 128 位如果需要 256 位密钥需要替换 JCE 无限制权限策略文件Java 8u161 之后和 Java 9 开始已经默认支持。在 Android 上从 Android 9API 28开始支持 256 位 AES但不同厂商的 ROM 可能有自己的限制。如果用的是 256 位密钥恰好又在较老的 Android 设备上可能会出现InvalidKeyException这跟数据库字符串没有关系但往往会在还原密钥后的第一次加解密时暴露。4.3 还原出的 SecretKeySpec 不能直接拿去生成字符串存回去有的人会把“还原失败”的锅甩给密钥实际是写回数据库时出了问题。比如项目里同时存在两套工具类一套用 Base64一套用 Hex存的时候用了 A 工具读的时候用了 B 工具结果自然是解不开。我还见过这样的场景某个加密服务把数据库里的密钥字符串取出来用 Base64 解码后得到了一个SecretKeySpec接着在日志里用key.getEncoded().toString()打出“密钥”看到一堆[B1f2f3f4这是 byte 数组默认的 toString 结果然后又把这一行日志内容复制回数据库。这等于把密钥从 Base64 字符串换成了无意义的对象引用字符串整个流程直接断掉。关键原则是密钥在数据库里的形态要从一而终。写入时用 Base64 编码的字符串读取后也必须只用 Base64 解码中间不要引入其他编码方式。如果不放心可以在数据库字段旁边加一个备注字段比如key_encoding BASE64让后面接手的人不至于猜。5. 常见问题与排查记录5.1 解码后长度不对问题出在哪先看一个高频报错IllegalArgumentException: Input byte array has incorrect ending byte at 24。这说明 Base64 字符串长度不对或者结尾填充字符被截断了。密钥长度和 Base64 字符串长度有严格对应关系16 字节密钥 Base64 后是 24 个字符24 字节密钥是 32 个字符32 字节密钥是 44 个字符。如果你从数据库读出来的字符串长度不是 24、32 或 44那几乎可以肯定在写入时发生了截断。尤其是数据库字段用的是VARCHAR(20)存 24 个字符的 Base64 字符串时JDBC 驱动不会报错但数据会在写库时被截断。排查思路很简单查一下数据库里这个字段的长度。如果长度小于理论上需要的长度第一优先级是修改表结构第二优先级是重新生成密钥并迁移数据。不要试图用算法去“补齐”缺失的 Base64 字符那只会让密钥的字节内容变成错误数据。Hex 也一样。16 字节密钥对应 32 个 Hex 字符24 字节是 48 个32 字节是 64 个。如果少了字符几乎都是列长度截断导致。还有一种是写入时把字符串转成了 Unicode 再存每个中文字符占两个字节导致读取时长度翻倍。这种情况只要统一用 ASCII 的 HEX 字符就不会有。5.2 加解密时出现 BadPaddingExceptionBadPaddingException几乎是 AES 相关故障里最常见的一个。它字面意思是“填充错误”但真正原因往往不只是填充问题。在 CBC 模式下如果密钥、IV 或密文中任何一个字节错误解密时会通过算法算出一个错误的“中间值”最后在校验 PKCS5 填充时失败从而抛出这个异常。所以你可以把它理解成“解密结果不对劲”的统称而不是具体的填充问题。排查步骤我一般按这个顺序来确认密钥字符串是否能正确还原成预期长度的字节数组。用一个已知的 Base64 字符串比如自己刚生成的一个密钥做加解密自检排除代码本身的问题。确认加密和解密使用的算法/模式/填充完全一致例如都是AES/CBC/PKCS5Padding。确认 IV 是否一致。CBC 模式下解密必须使用和加密时相同的 IV哪怕 16 个字节里错一个结果解密出来是乱码且大概率报错。最后才考虑数据库里的字符串本身是否在传输或读取过程中被修改。有人以为可以把密钥字符串打印到日志里看但这样做的风险很大。我自己的做法是打印密钥的 SHA-256 指纹比如用MessageDigest计算Base64.getEncoder().encodeToString(sha256(key.getEncoded()))只比对指纹是否一致。这样既不会把密钥完整暴露在日志里也能快速判断不同环境拿到的密钥是否相同。5.3 Android 与 Java 环境下的特殊注意事项Android 上的 AES 密钥还原逻辑与标准 Java 基本一样但有几个差异点很容易踩。java.util.Base64是 Java 8 才引入的。Android API 26 对应的是 Java 8 部分语法但java.util.Base64在 Android 上直到 API 26 才可用。如果你的应用还需要支持 Android 6-7建议使用android.util.Base64调用方式为android.util.Base64.decode(storedKey, android.util.Base64.DEFAULT)。注意它和java.util.Base64的 API 不完全一样传参方式也不同如果代码是同时给服务器和 Android 用容易混淆。Android 的Cipher实现和标准 JDK 也有细微差异。有些深度定制的 ROM 对AES/GCM/NoPadding支持不完整运行时会抛NoSuchAlgorithmException。稳妥的做法是先探测系统支持的算法或者在崩溃日志里单独记录算法名不要轻易假设所有 Android 设备行为一致。另外如果 Android 代码启用了混淆注意SecretKeySpec这类类名不能被混淆掉但它们通常也属于 Android 框架类混淆规则一般会保护javax.crypto.*。真正需要关心的是你自己写的工具类如果里面有反射或者依赖第三方库建议在proguard-rules.pro里加上-keep class规则避免混淆后找不到方法。有一次我在测试环境用了混淆包启动时一直报NoSuchMethodException后来排查发现是自定义 Base64 工具类被混淆了而android.util.Base64没有被调用到的原因。6. 我的建议从源头避免“字符串密钥”这种设计6.1 密钥管理的最佳实践方向回到标题最开始的问题“从数据库里读出来的字符串怎么变回能用的 AES 密钥”这个问题虽然常见但严格来说它暴露的是一个设计隐患。生产环境的密钥管理不应该把原始密钥以明文形式直接放在业务数据库里。在服务端推荐使用密钥管理系统或硬件加密机让应用向 KMS 请求密钥而不是自己保存密钥字节。在 Android 端推荐使用 Android Keystore。Keystore 底层的密钥可以存储在 Secure Element 或 TrustZone 中应用拿到的只是密钥别名真正执行加解密时私钥不会进入应用进程内存。那样就不存在“数据库读字符串还原密钥”的问题了。如果你是个人项目或内部工具至少也应该把密钥放到环境变量、独立的配置文件或者专门的密钥文件中并限制文件权限。直接放在数据库的普通字段里等于把保险柜钥匙和密码放在同一张桌子上。6.2 如果一定要用数据库字符串方案至少把这些做对我知道现实里有些老项目很难短时间改造成 KMS那么退一步如果必须走“数据库字符串”这条路线就坚持这几条规矩。第一统一使用 Base64并集中在工具类里处理。项目里不要同时存在 Base64 和 Hex 两种编码方式。第二数据库字段类型尽量用TEXT或VARCHAR(64)长度对 128 位密钥绰绰有余对 256 位密钥也能容纳。第三在字段命名上带上编码标记比如SECRET_KEY_B64这样后来的人一眼就知道该用什么解码。第四绝对不打印完整密钥最多打印指纹。第五写一个密钥自检方法在应用启动时跑一次确认数据库里的字符串能还原成合法密钥。最后分享一个小技巧我在代码里遇到new String(keyBytes)这类写法一定会当场把它改掉。因为等到线上加解密开始报错时你可能根本猜不到问题出在写入阶段。与其花两小时排查不如在一开始就把二进制数据的处理规范化。密钥这个东西只有字节序列在源头被正确保存字符串还原才真正有意义。
