Error occurs when adding Apple account security key #238

Open
opened 2025-12-30 15:31:24 +08:00 by michaelrrrrrr · 4 comments
michaelrrrrrr commented 2025-12-30 15:31:24 +08:00 (Migrated from github.com)

Tried to use Pico FIDO to add a security key to Apple account. I passed the PIN verification step, then an HTTPError popped up:

Image

Any idea what was going on here?

FIDO firmware version: 6.6
Dev board: Waveshare RP2350 Zero
Where to set up security key: macOS' System Settings

Tried to use Pico FIDO to add a security key to Apple account. I passed the PIN verification step, then an HTTPError popped up: <img width="952" height="962" alt="Image" src="https://github.com/user-attachments/assets/741e7506-5a60-4df4-8e0d-dd93991ceacb" /> Any idea what was going on here? FIDO firmware version: 6.6 Dev board: Waveshare RP2350 Zero Where to set up security key: macOS' System Settings
polhenarejos commented 2025-12-30 17:14:45 +08:00 (Migrated from github.com)

It is a known problem but no idea on why.

It is a known problem but no idea on why.
wlatendresse commented 2025-12-30 20:49:50 +08:00 (Migrated from github.com)

It is a known problem but no idea on why.

After examining the CTAP portion of the code for some time, I believe it would be very beneficial to have more "readable" information in troubleshooting situations.

In other words, I would personally design the "debug version" of the firmware so that the coded parts of the protocol are available in a readable format, allowing anyone to investigate problems "by reading the textversion of the protocol."

Perhaps it would be possible to retrieve this data from the Pico stick using a large blob out of "dummy credentials" without even the need for a debug probe?

And yes, I know that such ideas feel like a thorn in the side of an already existing and well-developed project.

But the flip side is that in software development, the second version is almost always the good one.

> It is a known problem but no idea on why. After examining the CTAP portion of the code for some time, I believe it would be very beneficial to have more "readable" information in troubleshooting situations. In other words, I would personally design the "debug version" of the firmware so that the coded parts of the protocol are available in a readable format, allowing anyone to investigate problems "by reading the textversion of the protocol." Perhaps it would be possible to retrieve this data from the Pico stick using a large blob out of "dummy credentials" without even the need for a debug probe? And yes, I know that such ideas feel like a thorn in the side of an already existing and well-developed project. But the flip side is that in software development, the second version is almost always the good one.
polhenarejos commented 2025-12-30 21:25:02 +08:00 (Migrated from github.com)

The problem is not the protocol itself, as it has been deeply tested. The problem is in the macOS side, which rejects the credential without any useful information or explanation. Furthermore, this "HTTPError" when adding a local credential is even more cryptic.

The problem is not the protocol itself, as it has been deeply tested. The problem is in the macOS side, which rejects the credential without any useful information or explanation. Furthermore, this "HTTPError" when adding a local credential is even more cryptic.
wlatendresse commented 2025-12-30 23:37:07 +08:00 (Migrated from github.com)

@polhenarejos
I agree with you regarding the problem described here.

I think the person experiencing the problem would need to provide more information (perhaps network protocol traces? As a Linux user, I'm not familiar with the implementation mentioned above).

However, my comment was more general in nature. I've found that descriptive logs are always useful. And in debug versions, they don't hurt anyone, but are often helpful. But I'm sure you already know that.

@polhenarejos I agree with you regarding the problem described here. I think the person experiencing the problem would need to provide more information (perhaps network protocol traces? As a Linux user, I'm not familiar with the implementation mentioned above). However, my comment was more general in nature. I've found that descriptive logs are always useful. And in debug versions, they don't hurt anyone, but are often helpful. But I'm sure you already know that.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dearsky/pico-fido#238