Brian E Carpenter <[email protected]> wrote: >> > In any case, isn't the list of pledges itself a point of attack for >> > someone attempting to install a rogue device? So the security of the >> > list of pledges should perhaps be discussed in the Security > >> Considerations, even though it's outside the protocol itself. The >> Rogue device would have to come from a certified Manufacturer, >> i.e. one known to the Registrar. As per RFC8995 section 11.5: >> "Manually configuring each manufacturer's trust anchor." ... but, >> perhaps I don't understand your question well enough.
> Even so, it could be an unexpected device, couldn't it? Or am I allowed
> to install an extra keypad on a door without adding it to a database?
So you could obtain an additional ACME Coyote-Door 2000 keypad, same model as
already installed on the door, and you could attempt to onboard it.
Assuming it joined the network successfully, what would the application
security be? I can see a few situations:
1) the network does some remote attestation on keypad, and having determined
that it is sane, integrates it somehow into the network. It seems
unlikely that this would occur without a human having to decide which
doors the keypad should control.
2) But, let's assume that somehow it got integrated automatically.
Since the keypad has remote attestation on the software, and presumably
that includes tamper resistant cases, what could you do?
You can't manipulate what happens inside the keypad, so phishing attacks
seems difficult.
Of course, you could put dust on the keys to see what numbers are more
common, but you could do that to the real device, right?
3) I assume that the keypad does not activate the doors itself.
Rather, it securely communicates the keycodes to the authenticator.
(And BRSKI provided the keypad with trust anchors to make this possible)
So since you haven't got a keycode... what would you do?
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
