Description of issue: In some cases, during a fuzz attack, device will end-up generating non-resolvable RPA even though the setting is resolvable RPA. This will lead to phone not able to connect to our device and users being locked out until the next valid RPA comes (15 mins by default). Behavior is observed with pairing mode is set to "Waiting to initiate" and when optimization is configured for speed over size.

Steps to reproduce issue: Defensics test case # SMP legacy 1001, loop.
multirole setting:

• change pairing mode to wait for initiate.
• change optimization to speed instead of size

During the fuzz attack, the crypto wasn't able to decrypt some of the packets and leads to link termination with MIC_error which then triggers RPA changing.
However, at this point crypto isn't ready to restart generate hash for RPA so it returns AESECB_STATUS_ERROR under AESECB_startOperation function. Stack has no check on the crypto status and just used invalid hash for the RPA which results in RPA being non-resolvable.