On Wed, Jul 31, 2019 at 11:11:54AM +0000, Mendelson, Tsippy wrote:
> Hi,
>
> My remark was about the inaccurate reference to IEEE 802.1AR requiring Serial
> Number as a MUST in the IDevID - this can be easily fixed by saying that IEEE
> 802.1AR recommends this but BRSKI enforces this - makes this a MUST.
Ack.
> But behind the scenes this question was coming from considerations related to
> complexity that this adds to the manufacturing flow when required to
> provision every device with a certificate that includes its Serial Number :-).
> This creates usability and security issues on the manufacturing line.
Thanks. Thats what i was guessing im my reply.
> We are devising a solution for this manufacturing problem by using an
> embedded CA in a RoT / Hardware TEE in the platform for this purpose - but
> there are concerns with this implementation as well. Therefore I wanted to
> clarify this requirement. (Although I agree that it makes perfect sense).
>
> Regarding:
> " If you just let the device generate a public key pair and you simply
> capture the public key during manufacturing, maybe that is a significant
> simplification when you talk 10 million devices"
>
> This is a very interesting remark as we are actually thinking of a solution
> where the Platform Identifier in the Ownership Voucher (that the OEM uploads
> to their inventory from the manufacturing line) would include 2 components:
> 1. The Serial Number assigned by the OEM to the platform - this could be a
> Service Tag or perhaps a hash of all serial numbers of devices included in
> the platform - or something else the OEM chooses - but as it can be a hash we
> allocate 32 bytes for it.
I can not quite imagine what you are calling a "platform". Could give
give one or two examples ?
> 2. A hash of the Public Key of a key pair that is generated by the Platform
> RoT for identity / TEE - this would be the public key in the IDevID
> certificate. When using an embedded CA (in the RoT hardware) to issue IDevID
> certificates, this would be the Public Key in the certificate of the embedded
> CA that the IDevID Certificate is rooted to.
RoT ? TEE ?
> Altogether 64 bytes.
>
> Using an embedded CA enables revoking and replacing the key and certificate
> used for identity attestation easily, after a FW update that increases the
> security version number.
See above, i can't quite imagine the solution and its intended
workflows, but it sounds as if oyu wanted to figure out a variation of
BRSKI/MASA
to actually enroll IDevID instead of LDevID...
It seems the main problem you want to solve is how client devices should
identify themselves to the MASA (or however else you want to call the
manufacturer or OEM backend) without a classical certificate IDevID and
without upfront tracking of any other form of serial IDs by the
manufacturer ?
I am not sure about all useful crypto mechanisms to solve this, but
obviously you could have something like a platform-id in a TPM chip
thats the same for all devices for the platform, and the only operation
permitted is some proof of knowledge of that shared secret by the MASA
(e.g.: hash(nonce+secret) or the like).
Of course if you can born something unique into the devices during
manufacturing, you could do something like very_long_serial=random(seed), seed
becomes the platform identifier, and device identifies by sending
masa-private-key encrypted serial to MASA. Or something like that.
Crypto folks would likely have better suggestions ;-)
Cheers
Toerless
> Regards,
> Tsippy
>
> -----Original Message-----
> From: Brian E Carpenter [mailto:[email protected]]
> Sent: Wednesday, July 31, 2019 05:18
> To: Toerless Eckert <[email protected]>; Michael Richardson
> <[email protected]>
> Cc: Jayanna, Prabhu <[email protected]>; Mendelson, Tsippy
> <[email protected]>; [email protected]; Ruan, Xiaoyu
> <[email protected]>
> Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to
> IEEE 802_1AR-2009
>
> Let's be clear in the BRSKI text that our standard makes this a MUST *even
> if* it is not mandatory in the IEEE standard. Of course we can do that (and
> not including the serial number seems very sloppy), but we should be explicit
> that our requirement is stronger than the IEEE.
>
> Maybe it means that some light bulbs cannot be BRSKI pledges. I don't think
> we care, because our model is that nodes containing management smarts such as
> an ASA need to join the ACP, but managed nodes themselves do not.
>
> Regards
> Brian
>
> On 31-Jul-19 11:11, Toerless Eckert wrote:
> > On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote:
> >>
> >> Toerless Eckert <[email protected]> wrote:
> >> > From what i understand (and please correct me if you are coming from
> >> a
> >> > different angle), you may be able to reduce cost in manufacturing of
> >> > low-cost and/or constrained device by not having to have IDevID
> >>
> >> I didn't get that all from the original poster.
> >> I think you are jumping to a conclusion that is not supported by text here.
> >
> > Yes, i was elaborating about why one would want an IDevID without the
> > serialNumber and what would need to happen to support that. But i also
> > said this should be out of scope for the current BRSKI document.
> >
> >> They simply say that serialNumber is not a MUST in 802.1AR-2018, but
> >> rather a SHOULD.
> >> And, that's not the point at all, really.
> >> IF you want to do BRSKI, then you MUST include a serialNumber in the DN.
> >
> > Agreed.
> >
> >> 802.1AR-2009, has section 7.2.8:
> >>
> >> 7.2.8 subject
> >> The DevID subject field shall uniquely identify the device associated
> >> with the particular DevID credential within the issuer???s domain of
> >> significance. The formatting of this field shall contain a unique
> >> X.500
> >> Distinguished Name (DN). This may include the unique device serial
> >> number assigned by the manufacturer or any other suitable unique DN
> >> value that the issuer prefers. In the case of a third-party CA or a
> >> standards certification agency, this can contain the manufacturer???s
> >> identity information.
> >>
> >> The subject field???s DN encoding should include
> >> the ???serialNumber??? attribute with the device???s unique serial
> >> number.
> >>
> >> Note lack of RFC2119 language (or a reference to it).
> >>
> >> So if the 2018 has "SHOULD" here, then that's a strengthing of the
> >> language, not a weaking.
> >> The first paragraph does have weasel words "any other suitable unique
> >> DN", but
> >
> > Ok, i currently can't access the IEEE standards, so i can not compare
> > myself. My reading of the OP was that it was a weakening.
> >
> >
> >> I really think that a serialNumber DN attribute (as opposed to the
> >> serialNumber certificate attribute) is needed for BRSKI to
> >> interoperate well.
> >
> > Agreed.
> >
> >> If someone has a 10 million devices in the field which can be field
> >> upgraded to run BRSKI (while still in a not-yet enrolled state in a
> >> box), then let's talk about this. Maybe it's actually 10,000,000 TPM
> >> devices with IDevIDs already generated, but no serialNumber in it.
> >> Getting the JRC code right to do other things can be a pain, but it can be
> >> done.
> >
> > Right, this was my question to the OP as well. I was guessing its more
> > about minimizing cost for future built 10 million devices. Today you
> > would need to burn-in during manufacturing identity elements such as
> > specifically the serialNumber, so you need to devise a protected
> > burn-in process. If you just et the device generate a public key pair
> > and you simply capture the public key during manufacturing, maybe that
> > is a significant simplification when you talk 10 million devices. Just
> > guessing. In any case, serialNumber is a lot more useful when humans
> > are involved, but they may become less relevant when everything is
> > automated.
> >
> > Cheers
> > Toerless
> >
> >> --
> >> ] Never tell me the odds! | ipv6 mesh
> >> networks [
> >> ] Michael Richardson, Sandelman Software Works | IoT architect
> >> [
> >> ] [email protected] http://www.sandelman.ca/ | ruby on rails
> >> [
> >>
> >
> >
> >
> >> _______________________________________________
> >> Anima mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/anima
> >
> >
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
