This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] LP-EM-CC1354P10:ECDSA 签名验证失败

Guru**** 2331900 points
Other Parts Discussed in Thread: CC1354P10, SYSCONFIG
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1463722/lp-em-cc1354p10-ecdsa-signature-verification-fails

器件型号:LP-EM-CC1354P10
主题中讨论的其他器件:CC1354P10SysConfig

工具与软件:

您好!  

我正在使用在 CC2642R1上运行的 SDK 3.40.00.02和 IAR 8.32.2将代码库移植到在 CC1354P10上运行的 SimpleLink SDK 7.41.00.17和 IAR 9.40.2。 在之前的代码库中、我能够顺利进行 ECDSA 签名验证。 但通过这一新代码库、 我发现如果 BLE 连接处于活动状态、我的其中一个签名验证操作会失败 ECDSA_VERIFY、但如果器件未处于活动连接中(即使使用完全相同的公钥、消息和签名)、也能正常工作。 如果操作失败、ECDSA_VERIFY 返回-1、我假定如果发现签名无效、则会返回错误代码。 在 SysConfig 中、我尝试了同时使用 ECDSA 模块的单个实例和2个实例(如果 BLE 堆栈使用的是第一个实例)。 但在两种情况下、我都遇到了相同的问题。 总而言之、我的问题是:

  1. 当连接处于活动状态时、什么可能导致 ECDSA_VERIFY ()返回错误状态、否则、对于相同的密钥、消息和签名、返回成功?
  2. 为了成功运行 ECDSA 驱动程序、我是否需要添加 ECDSACC26X4_s.c、ECDSACC26X2.c 或任何其他堆栈文件? 我已在项目中尝试了是否包括 ECDSACC26X2.c、但无论如何我都会得到相同的结果。 当我尝试在项目中包含 ECDSACC26X4_s.c 时、我会收到以下屏幕截图中所示的编译错误:

请提供建议。

谢谢!

Keron

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Keron:

    感谢您的详细说明。 由于您要从旧 SDK 移植到另一个器件、因此需要考虑许多更改。
    首先、我想指出的是、我们已发布了较新的 SDK 8.30: https://www.ti.com/tool/download/SIMPLELINK-LOWPOWER-F2-SDK/8.30.00.121

    现在、让我们深入探究您的问题:

    1. 什么原因可能导致 ECDSA_VERIFY ()在连接处于活动状态时返回错误状态,否则,对于相同的密钥、消息和签名返回成功?

    -您能给我澄清一下吗:连接处于活动状态, BLE 堆栈正在运行,没有连接设备 或者 表示 BLE 堆栈未运行?

    2. 是否需要添加 ECDSACC26X4_s.c、ECDSACC26X2.c 或任何其他堆栈文件才能成功运行 ECDSA 驱动程序? 我已在项目中尝试了是否包括 ECDSACC26X2.c、但无论如何我都会得到相同的结果。 当我尝试在项目中包含 ECDSACC26X4_s.c 时、我会收到以下屏幕截图中所示的编译错误:

    -当您在 SysConfig 中添加 ECDSA 实例时,它会自动包括所需的源文件。
    -如何添加和初始化  ECDSA 实例?


    3.您能解释一下您是如何导入项目的吗? 您是否从 CC1354P10示例项目开始并添加了您的功能?


    此致、
    等等

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Theo:

    感谢您深入了解该问题。 同时也感谢大家认真学习更新后的 SDK。 我曾尝试查看该链接中引用的更改日志、但它导致404错误。 在其他任何地方我都可以了解 SDK 的差异?

    请在下面查看我对您问题的答复:

    1. 您可以向我澄清一下:连接处于活动状态是指 BLE 堆栈正在运行、未连接任何器件 还是 BLE 堆 栈未运行?

    -我应该已经提到我们的代码库基于 simple_central 示例项目之上、所以我的所有用例中都在运行 BLE 堆栈任务。 当我说 ECDSA 在连接处于活动状态时失败时、我指的是正在运行的 BLE 堆栈任务、且我的器件连接到另一个对等器件。 我的设备设置为 simple_central、对等设备为外设。 当两个器件处于有效 BLE 连接中时、ECDSA 验证失败、对于我的其中一个验证操作、状态为-1。 但是、如果两个设备未处于有效的 BLE 连接中、则针对相同的密钥、消息和签名成功进行相同的 ECDSA 验证。  

    2.如何添加和初始化 ECDSA 实例?

    -在 SysConfig 中,我有几个使用所有默认设置(即 CONFIG_ECDSA_0和 CONFIG_ECDSA_1 )定义的 ECDSA 实例。 然后在代码中,我在 BIOS_start()启动 RTOS 后调用 ECDSA_init()。 稍后、当我需要执行签名验证时、我通过包装器函数执行以下操作:

    ECDSA_Handle ecdsaHandle = ECDSA_open(CONFIG_ECDSA_1, nullptr);
    if (ecdsaHandle == nullptr)
    {
        // return error
    }
    
    /// Initialize the public key.
    CryptoKey peerPublicKey;
    CryptoKeyPlaintext_initKey(
        &peerPublicKey,
        uncompressedEcdsaPublicKey), // previously defined 65 byte public key (i.e. 0x04, X, Y)
        65);
    
    /// Initialize the verification operation.
    ECDSA_OperationVerify operation;
    ECDSA_OperationVerify_init(&operation);
    operation.curve = &ECCParams_NISTP256;
    operation.theirPublicKey = &peerPublicKey;
    operation.hash = hashToVerify; // previously defined 32 byte hash
    operation.r = signature; // first 32 bytes of previously defined signature
    operation.s = signature + 32; // last 32 bytes of previously defined signature
    
    /// Verify the signature.
    status = ECDSA_verify(ecdsaHandle, &operation);
    
    /// Close the driver.
    ECDSA_close(ecdsaHandle);

    正如我所提到的、如果 BLE 连接处于活动状态、ECDSA_VERIFY ()调用会针对某个密钥、消息和签名返回-1、但如果 BLE 连接断开、则返回0 (成功)。 我不知道如果 BLE 连接处于活动状态、为什么驱动器的行为会有所不同。

    3.您能解释一下您是如何导入项目的吗? 您是否从 CC1354P10示例项目开始并添加了您的功能?

    - 是的、 我遵循 TI 的建议程序来更新到较新的 SDK。 我一开始使用的是 CC1354P10 simple_central 示例项目、然后将我之前代码库中的应用代码复制到这个新代码库中。 到目前为止、除了此 ECDSA 问题之外、其他方面似乎总体上运行良好。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Keron:

    首先更新的链接:

    感谢您的详细回答。
    移植过程似乎正确、我很高兴听到其余功能按预期运行。

    此问题 听起来像是同步问题。 您是否可以检查调用 ecdas_verify 时的操作和 ecdsaHandle 的 初始化方式与 您有连接和没有连接时相同?

    此外、请与调试器核实 ECDSA_VERIFY 是否在两种情况下实际执行验证。

    此致、
    等等

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Theo:

    感谢链接。 我最初可以访问它们、但当我提到404错误时、我指的是 SDK 发行说明中引用的"更改日志"链接。 到更改日志的链接是无效链接。 我想查看更改日志、以便查看自 SDK 7.41.00.17以来已经进行了哪些 SDK 更改。

    我分别仔细检查了您提到的内容。 我在运行调试器时使用了观察窗口、并确认在 有连接和没有连接时"ECDSA_OperationVerify"和"ECDSA_Handle"对象的成员变量完全相同。 我还使用调试器确认 ECDSA_VERIFY 在两种情况下都会执行验证。 但如前所述、由于某种原因、 当连接处于活动状态时、ECDSA_VERIFY 会针对一组相同的参数返回-1、这些参数与在连接未处于活动状态时返回成功的参数相同。

    当我查看反汇编和映射文件时、我注意到的一点是 ECDSA_VERIFY ()的代码位于0x76535、其他与 ECDSA 相关的功能位于附近(请参阅随附的屏幕截图)。 我认为这是闪存、而不是 ROM。 另外、映射文件显示这些定义根目录位于 ECDSACC26X2.c.obj 中。 由于这是 CC13x4处理器、定义是否来自 ECDSACC26X4_s.c 等文件? 我不知道为什么在这个代码库中使用 ECDSACC26X2.c 模块、因为我没有将它包含在我知道的任何地方。 这是否会导致一些问题、或者您是否有其他想法?

    谢谢!

    Keron

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Keron:

    非常感谢您的澄清。 我确认更改日志链接已关闭、并提交了一个 TT 以替换它。

    在 SysConfig 中定义 ECDSA 实例时、它会自动包括相关驱动程序。 右键点击 CCS Explorer 中的工程并打开工程属性("Resource"->"Linked Resources")后、您可以看到文件的导入位置。

    能否和我分享一下这张截图吗? 我想确认的是、它会从7.41 SDK 中导入所有内容。

    当在工程属性中点击"Build"->"SysConfig"并点击"Build"->"Arm Compiler"时、还可以验证它是否使用7.41 SDK。

    除此之外、我只能想象该函数以某种方式被阻止、因为它的优先级低于主动链。 您可以尝试使用指针将数据传递到不同的线程或任务上下文、并在连接范围之外执行检查。

    此致、
    等等

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Theo:

    我使用 IAR 9.40.2进行开发、而不是 CCS。 是否有办法检查您使用该配置指示的内容?  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Keron:

    当然。 您也可以从导入链接资源的位置签入 IAR。
    您只需检查它是否已链接到7.41 SDK 的安装目录中。

    如果是这种情况、请告诉我。

    此致、
    等等

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Theo:

    不幸的是、我仍然面临这个问题。  此外, 我注意到的其他一些奇怪的行为是,当 ECDSA_verify ()操作在 BLE 连接时返回不良状态时,通常在断开连接时触发的 GAP 相关回调将永远不会被调用。 因此、 当我看到 ECDSA_VERIFY 操作失败时、器件似乎整体进入了非常糟糕的状态。 您是否对可能发生的情况有任何想法? 我认为这超出了资源争用问题。 请提供建议。

    谢谢!

    Keron

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Keron、

    您能否快速尝试增加连接间隔并检查操作是否仍然失败以及运行频率如何? 我还不会放弃资源争用问题。 但是、  如果是这种情况、驱动程序函数应导致 ECDSA_STATUS_resource_unavailable (-2)、而不是 ECDSA_STATUS_ERROR (-1)。 我想问一下、您是否在此基础上使用了任何其他加密机制? 堆栈本身支持其他加密功能、这些加密功能可能与 ECDSA 函数一起执行、从而可能导致意外问题。 此外,您能否在 ECDSA_VERIFY ()函数中设置一个断点,然后跳过以查看函数内部验证失败的位置,以及它与没有连接正在进行的情况有何不同? 最后、您能否尝试将 ECDSA int 优先级提高到最高、以查看是否重现行为?

    此致、

    David。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 David:

    感谢您的答复。

    1.是否可以快速增加连接间隔并检查操作是否仍然失败以及运行频率如何?

    我已将连接间隔增加到可能的最高值(即4000ms)、但操作仍然始终失败。 只是为了提供更详细的信息...在连接期间、我对 ECDSA_VERIFY 进行了两次调用。 第一个调用始终成功。 但是、在连接期间几秒钟后发生的第二个调用始终返回-1 (尽管签名有效)。

    2.我想问一下您是否在使用此加密机制的基础上使用其他加密机制?

    是、我有:ECDH 模块的两个实例、1个 ECDSA 实例、1个 EDDSA 实例、1个 AESCCM 实例、1个 AESCTRDRBG、 1个 AESECB 和1个 SHA2实例。 请参阅随附的屏幕截图。

    3.您能否在 ECDSA_VERIFY ()函数中设置断点,然后逐步查看函数内部验证失败的位置,以及它与没有连接正在进行的情况有何不同?

    除非我在项目中包含 ECDSACC26X2.c、否则我实际上无法看到 ECDSA_VERIFY ()的内容。 否则、我只能查看反汇编。 假定我应该在本练习中包含 ECDSACC26X2.c、当单步执行该函数时、无论返回 Success 还是-1、执行似乎完全相同。 我看到的唯一区别是当 ECDSA_VERIFY ()调用 ECDSACC26X2_waitForResult ()并且 达到 ECDSA_RETURN_ACISTY_BLOCKING 实  例时,在 SemaphoreP_PEND ()调用后,object->operationStatus 对于失败的情况为-1而对于成功的情况为0。 但不清楚是什么导致了故障。

    4.您可以尝试将 ECDSA 的 int 优先级提高到最高,看看行为是否重现?

    是的,这是我尝试的第一件事,但不幸的是,即使是一个 int 优先级1没有帮助. 我获得相同的结果。

    BTW 另一个细节:当我进入状态,当 ECDSA_VERIFY ()在连接期间返回错误状态时,UART 不再工作,我必须重置芯片才能使东西再次工作。 我认为芯片作为一个整体会变得灵敏。 请提供建议。

    谢谢!

    Keron

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Keron、

    感谢您的答复。 当您提到对 ECDSA_VERIFY ()的第一次调用有效而 sencond 不有效时,两者是否都在连接事件中执行? 此外、您能否分享您使用 ECDSA 函数调用包装器函数的代码位置? 例如、您是通过驱动程序回调函数调用它吗? 共享更多代码片段或有关代码执行顺序的详细信息将很有帮助、因为它会在较高优先级的上下文中显示一个信标挂起。

    谢谢。

    David。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 David:

    当您提到对 ECDSA_VERIFY ()的第一次调用有效而第二次不有效时,两者都是在连接事件中执行的吗?

    ECDSA_VERIFY ()两个调用都是在我的设备与对等设备处于活动 BLE 连接时执行的,但我不确定它们是否在链路层上发生连接事件时执行(如果这是您所问的)。

    此外、您能否分享您使用 ECDSA 函数调用包装器函数的代码位置? 例如、您是通过驱动程序回调函数调用它吗?

    否、我不会从回调中执行任何此代码。 我只使用配对状态回调进行事件排队、该事件最终会从主应用任务的事件处理程序中启动 ECDSA_veridy 调用序列。 总结:

    1.我的设备连接到对等设备并通过 BLE 配对/绑定。  

    2.当 达到配对状态回调的 GAPBOND_PAIRING_STATE_BOND_SAVED 情况时,我会排队等待一个事件,该事件在我的主要应用程序任务的事件处理程序中得到处理。 该事件处理程序发出第一个 ECDSA_VERIFY 调用。

    3.设备随后交换更多信息,导致另一个事件在第一次 ECDSA_VERIFY 调用后几秒钟进入队列。 当我的主应用程序任务的事件处理程序循环处理该事件时、会进行第二个 ECDSA_VERIFY 调用。 这是返回状态-1的调用。

    也许我可以私下给您发送我的代码。 我将离线联系您。

    谢谢!

    Keron

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Keron:

    我通过邮件联系到你。
    接下来我们讲解一下。

    此致、
    等等