在 .NET Core 中使用 ECDSA384 进行 JWT 签名验证（MacOS 兼容性问题）答案

【问题标题】：Using ECDSA384 for JWT signature validation in .NET Core (MacOS compatibility problem)在 .NET Core 中使用 ECDSA384 进行 JWT 签名验证（MacOS 兼容性问题）
【发布时间】：2019-12-08 03:48:52
【问题描述】：

我有一个公钥，现在我不确定如何使用它来验证 JWT 令牌的签名。我已经尝试使用here 所示的想法（用于验证），但不同之处在于我使用的是 384（在示例中不是 256）并且不确定我应该跳过数组中的哪些字节并进入考虑。我也尝试过使用同样失败的外部库，可能是出于同样的原因。我不确定如何从我拥有的公钥字节数组中提取 X 和 Y。这些例子似乎都假设你已经知道 X 和 Y：

字符串标记 = "eyJhbGciOiJFUzI1NiIsImN0eSI6InRleHRcL3BsYWluIn0.eyJoZWxsbyI6ICJ3b3JsZCJ9.EVnmDMlz-oi05AQzts-R3aqWvaBlwVZddWkmaaHyMx5Phb2NSLgyI0kccpgjAyo1S5KCB3LIMPfmCX_ob";

byte[] x = { 4, 114, 29, 223, 58, 3, 191, 170, 67, 128, 229, 33, 242, 178, 157, 150, 133, 25, 209, 139, 166, 69, 55, 26, 84, 48, 169, 165, 67, 232, 98, 9 };
byte[] y = { 131, 116, 8, 14, 22, 150, 18, 75, 24, 181, 159, 78, 90, 51, 71, 159, 214, 186, 250, 47, 207, 246, 142, 127, 54, 183, 72, 72, 253, 21, 88, 53 };

var publicKey=EccKey.New(x, y);

string json = Jose.JWT.Decode(token,publicKey);

此外，当我伪造字节数组以克服由于 X 和 Y 大小不正确等原因导致的初始异常时，我发现我仍然有 100% 的时间出现异常。我将此问题追溯到这样一个事实，即我正在使用的所有库都在尝试创建一个 CngKey，这会导致“不受支持的平台异常”，因为我在 MacOS 上进行开发。

鉴于信息表here，我看到了这样的解释：这是有道理的。但是，我希望避免仅仅使用ECDsaOpenSsl 并安装 OpenSSL 就必须实现我自己的这些库实现，并且我希望能够部署到 Windows 环境而无需检查哪个操作系统正在执行代码。

总结起来有2个问题：

我不确定如何从我的公钥字节中提取 X 和 Y 坐标大批。我链接的第一个例子来自一个知道数组的第一个索引被跳过，数组的其余部分被平均分割。如果我我的数组会有奇数位数这样做了，所以我不确定要跳过哪些索引，如果它甚至适用在这里。
我希望在验证签名时能够进行奇偶校验 Mac 和 Windows 都没有滚动我自己的库。

【问题讨论】：

(1) 如何从密钥中确定x 和y 取决于密钥格式。你能说一下格式或发布密钥吗？ (2) CNG 和ECDsaCng 仅适用于 Windows。 ECDSa 使用ECDsa.Create() 支持跨平台，它实例化特定平台使用的类型（例如Windows 上的ECDsaCng）。您是否在 .Net / macOS 上尝试过，另请参阅 here 和 here？
@Topaco 这些链接内容丰富且有用 - 谢谢。这是我请求的本地密钥的临时版本：cutt.ly/CruTp2l 它是用 secp384r1 编码的 base 64
发布的公钥以 X.509 格式指定，here, section C.3，并且可以使用 ASN.1 解析器最容易地读取，例如here。最后，可以以未压缩格式04 | x (48 bytes) | y (48 bytes): 04 | ddd1...3ae7 | f01f...2314 找到原始公钥。 secp384r1 或 NIST P-384 描述为here, section 2.5。
当我将GetBytes(pubKey) 与我的密钥一起使用时，我得到一个包含 160 个元素的字节数组。你是说我需要得到 64-160 的范围并将它们分成 X 和 Y？
不完全。 Base64 编码的公钥MHYw...fyMU 的长度为160 字节。密钥必须是 Base64 解码的 first，例如here。 Base64解码后密钥长度为120字节，其中last 2*48+1=97字节为04 | x (48 bytes) | y (48 bytes)格式的原始公钥。但请注意，如果将 Base64 编码的公钥 MHYw...fyMU 存储在文本文件中，然后使用 ASN.1 编辑器打开以读取原始公钥，则要容易得多，请参阅 here。

标签： openssl cryptography jwt asp.net-core-2.2 jwt-auth

【解决方案1】：

我只对问题 1 发表评论：

在您链接的示例中，公钥是未压缩格式，始终编码为：

0x04 | X | Y

其中 X 和 Y 是无符号值，由对应于曲线大小的确切字节数表示（例如，256 位曲线为 32 个字节）。这就是示例跳过第一个字节，然后将剩余字节平均拆分以获得 X 和 Y 的原因。

为了帮助您使用公钥，您必须在此处发布此密钥。然后我们可以推测它的编码。

【讨论】：

另外，需要明确的是，主要问题是 Mac 不兼容。这就是赏金的用途。即使创建了有效的 ecckey，所有方法似乎都会产生平台不受支持的异常。