Anoop Kumar Pandey <an...@cdac.in> wrote:
> When a device is purchased in real world, usually an invoice is issued in
the
> name of the purchaser with stamp of vendor/manufacturer.
> I propose that similarly, a digital invoice can be issued which will
contain
> the public key(s) of the <domain owner(s)/JRC(s)> and digitally signed by
the
> manufacturer. The digital invoice may be embedded in the pledge along with
> the IDevID.
That's an interesting idea, perhaps you could write it up in the form of an
Internet-Draft? Then I could make sure that I fully understand your
proposal.
It seems very difficult to make digitally signed invoices occur in the real
world, given the constrained of the supply chain. Still, BRSKI makes
provisions for higher security if the supply chain is integrated.
I once proposed something similar using signed certficates:
https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00
In effect, the voucher artifact that we created in RFC8366 replaces these
certificates with purpose built signed artifacts that expresses what the
invoice attempts to express.
> When a pledge starts the registration process, it will present the digital
> invoice along with IDevID. The JRC can verify the digital signature of the
> manufacturer on the digital invoice and sent a signed note of acceptance
to
> the pledge. The pledge can verify the signed note using the public key(s)
> mentioned in the digital invoice, thereby verifying its true owner.
A pledge which has sat in a warehouse for a year before being sold to an
owner will not have the invoice on it yet. That's okay, because the invoice,
being digitally signed, could be retrieved from another place, and that's
effectively what the BRSKI-MASA protocol *does*.
If the invoice needs to be loaded into the Pledge via a secure-out-of-band
mechanism, (i.e. during the manufacturing process), then the Pledge could
also be fully configured, and could include a simple PSK too. This is the
approach which is being used in draft-ietf-6tisch-minimal-security.
Ultimately, it's not the JRC which is suspicious of who the Pledge's owner
is, it's the Pledge which does not know who owns it.
> This process with eliminate all the communication overhead with MASA and
> multiple level verification (voucher request, voucher, telemetry etc at
> JRC/MASA/Pledge).
Yes, it does, at the cost of making every device in the warehouse unique to a
specific customer. If I may make an analogy to distribution of movies,
you are suggesting that netflix go back to mailing DVDs to people.
> From security point of view: Given that the digital invoice is digitally
> signed by manufacturer, the public key of domain owner embedded in the
> digital invoice can’t be changed, otherwise verification of digital
signature
> of manufacturer at JRC end will fail.
> Requesting you to give your comments as it will simplify the protocol.
> P.S.: As you had earlier mentioned “On resale, the device should be put
> through a factory reset to clear things. The MASA will have to be willing
to
> issue a new voucher to the new domain owner..”; here also, manufacturer
may
> issue a new digital invoice in case of resale.
yes, that's true. But, since you said that the invoice is in the Pledge, the
manufacturer would have to take the device back to do that.
The reason for all the JRC,MASA etc, is so that we do not need to have the
manufacturer touch the device a second time.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
