+- Haxorware Forums (http://www.haxorware.com/forums)
+-- Forum: General (http://www.haxorware.com/forums/forumdisplay.php?fid=6)
+--- Forum: Modems (http://www.haxorware.com/forums/forumdisplay.php?fid=7)
+--- Thread: BPI + Authentication Explained by ABMJR (/showthread.php?tid=672)
BPI + Authentication Explained by ABMJR - ABMJR - 05-11-2010
http://www.sbhacker.net/forum/index.php/topic/32380-bpi-authentication-certificate-explanation/page__pid__158418#entry158418
--------------------------------------------------------------------------
BPI + Certificate Authentication
Summary of the CM Authentication and the
Code File Authentication
Authors Note: Please note the CVC errors in your log, as they pertain to the the failure of the CA Certificate.
The purpose of this appendix is to provide the overview of the two authentication mechanisms defined by
BPI+ specification and also to provide a example of the responsibility assignment for actual operation but
not to add any new requirements for the CMTS or the CM. Please refer BPI+ specification regarding the
requirement for the CMTS and the CM.
G.1 Authentication of the DOCSIS 1.1 compliant CM79
If the CMTS is compliant to the DOCSIS 1.1/BPI+ and a DOCSIS 1.1 compliant CM is provisioned to run
BPI+ by the CM configuration file, the CMTS authenticate the CM during the CM initialization by verifying
the CM certificate and the manufacturer CA certificate. These certificates are contained in Auth Info
message and Auth Request message separately and sent from the CM to the CMTS just after the CM
registration. Only the CM with the valid certificates will be authorized by the CMTS and become ready to
forward the user traffic. Note that this CM authentication won't be applied if the CMTS and/or the CM is not
compliant to BPI+, or the CM is not provisioned to run BPI+.
![[Image: xaw568.jpg]](http://i56.tinypic.com/xaw568.jpg)
Figure 10. Authentication of the DOCSIS 1.1 compliant CM
G.1.1 Responsibility of the DOCSIS Root CA
The DOCSIS Root CA is responsible for the following:
• Store the DOCSIS Root private key in secret.
• Maintain the DOCSIS Root CA certificate.
• Issue the manufacturer CA certificates signed by the DOCSIS Root CA.
• Maintain the CRL of the manufacturer CA.
• Provide the operators with the CRL.
It is not yet decided whether a manufacturer CA certificate signed by the DOCSIS Root CA is provided to
the CM manufacturer before applying for the CableLabs' certification process or after achieving the certified
status.
G.1.2 Responsibility of the CM manufacturers
The CM manufacturers are responsible for the following:
• Store the manufacturer CA private key in secret,
• Maintain the manufacturer CA certificate. The manufacturer CA certificate is usually signed by the
DOCSIS Root CA but can be self-signed until the DOCSIS Root CA issues it based on the CableLabs
policy.
• Issue the CM certificates,
• Put the manufacturer CA certificate in the CM's software,
• Put each CM certificate in the CM's permanent, write-once memory.
• Provide the operators with the hot list of the CM certificate. The hot list may be in the CRL format.
However, the detail of the format and the way of delivery are TBD.
G.1.3 Responsibility of the operators
The operators are responsible for the following:
• Maintain that the CMTS(s) have an accurate date and time. If a CMTS has a wrong date or time, the
invalid certificate may be authenticated or the valid certificate may not be authenticated.
• Put the DOCSIS Root CA certificate in the CMTS during the CMTS provisioning using DOCS-BPI2-
MIB or the CMTS's proprietary function. The operator may have a server to manage this certificate for
one or more CMTS(s).
• Put the manufacturer CA certificate(s) in the CMTS during the CMTS provisioning using DOCS-BPI2-
MIB or the CMTS's proprietary function (optional). The operator may have a server to manage this
certificate for one or more CMTS(s).
• Maintain the status of the certificates in the CMTS(s) if desired using DOCS-BPI2-MIB or the CMTS's
proprietary function (optional). The operator may have a server to manage all the status of the
certificates recorded in one or more CMTS(s).
The operator may have a server to manage the DOCSIS Root CA certificate, manufacturer CA
certificate(s) and also the status of the certificates recorded in one or more CMTS(s).
• Maintain the hot list for the CMTS based on the CRLs provided by the DOCSIS Root CA and the CM
manufacturers (optional). The operator may have a server to manage the hot list based on the CRLs
provided by the DOCSIS Root CA and manufacturer CAs. The CMTS may have a function to
automatically download the DOCSIS Root CA certificate and the CRLs via the Internet or other
method. The DOCSIS Root CA or CableLabs is likely to put the DOCSIS Root CA on their Web or
TFTP server in order to let the operators (or the CMTS on behalf of the operator) download it but this is
not yet decided.
G.2 Authentication of the code file for the DOCSIS 1.1 compliant CM
When the DOCSIS 1.1/BPI+ compliant CM downloads the code file from TFTP server, the CM must always
authenticate the code file as defined in the appendix D of [SP-BPI+-I03] regardless of whether the CM is
provisioned to run BPI+, BPI or none of them by the CM configuration file. The CM installs the new image
and restart using it only if the CVC(s) and the signature(s) in the code file are verified. If the authentication
fails because of the invalid CVC(s) or signature(s) in the code file, the CM rejects the code file downloaded
from the TFTP server and continues to operate using the current code. The CM accepts the order of the
software downloading via the CM configuration file or the MIB only if the CM is properly initialized by the
CVC(s) in the CM configuration file. In addition to the code file authentication by the CM, the operators
may authenticate the code file before they put it on the TFTP sever. The following figure shows the
summary of these mechanisms.
![[Image: etyyig.jpg]](http://i56.tinypic.com/etyyig.jpg)
G.2.1 Responsibility of the DOCSIS Root CA
The DOCSIS Root CA is responsible for the following:
• Store the DOCSIS Root private key in secret,
• Maintain the DOCSIS Root CA certificate, and
• Issue the code verification certificates (CVCs) for the CM manufacturers, for the operators, and for
"CableLabs Certified™".
• May maintain the CRL of the CVCs and provide it with the operators but not yet decided.
G.2.2 Responsibility of the CM manufacturer
The CM manufacturers are responsible for the following:
• Store the manufacturer CVC private key in secret,
• Put the DOCSIS Root CA certificate in the CM's software,
• Maintain the manufacturer CVC. (Current BPI+ specification only allows the CVC signed by the
DOCSIS Root CA and does not accept the self-signed CVC.)
• Generate the code file with the manufacturer's CVC and signature, and
• Provide the operators with the code file and the manufacturer CVC,
G.2.3 Responsibility of CableLabs
CableLabs is responsible for the following:
• Store the "CableLabs Certified™" CVC private key in secret,
• Maintain the "CableLabs Certified™" CVC signed by the DOCSIS Root CA.
• Issue the "CableLabs Certified™" signature file for the DOCSIS 1.1 CM code file certified by
CableLabs.
G.2.4 Responsibility of the operators
The operator has the following responsibility and options:
• Check the manufacturer of the code file by verifying the manufacturer's CVC and signature in the code
file provided by the CM manufacturer before the operator load the code file on the TFTP server
(optional). The code file may be rejected and won't be loaded on the TFTP server if the unexpected
manufacturer signs it or the CVC and/or the signature in it are invalid.
• Check if the code file provided by the CM manufacturer is "CableLabs Certified™" by verifying the
"CableLabs Certified™"'s CVC and signature in the "CableLabs Certified™" signature file against
the code file before the operator load the code file on the TFTP server (optional). CableLabs is likely to
post all the "CableLabs Certified™" signature files and also the corresponding certified code files on
the web or FTP server while this is not yet decided. Whether this information is open to only the
CableLabs members, all the operators, all the vendors, or pubic is not yet decided
• Operate the operator CA by storing the operator CA private key in secret and maintaining the
operator's (co-signer) CVC issued by the DOCSIS Root CA (optional).
• Generate the MSO-controlled code file by adding the operator's CVC and signature to the original code
file provided by the CM manufacturer (optional).
• Check if the CVC provided by the CM manufacturer is valid (optional).
• Put the appropriate CVC(s) in the CM configuration file. In case that the original code file is to be
downloaded to the CMs, the CM configuration file must contain the valid CVC from the CM's
manufacturer. In case that the operator-controlled code file is to be downloaded, the CM configuration
file must contain the valid CVC of the operator and may contain the valid CVC from the CM
manufacturer. If there is no CVC in the CM configuration file or all the CVC(s) in the CM configuration
file is invalid, the CM won't accept any order of the software downloading via the CM configuration file
and the MIB. Note that the DOCSIS 1.1 compliant CM may be registered and authorized by the CMTS
and becomes operational regardless of whether the CM configuration file contains the valid CVC(s).
RE: BPI + Authentication Explained by ABMJR - drewmerc - 29-09-2011
thread cleaned of useless off topic crap
RE: BPI + Authentication Explained by ABMJR - ABMJR - 31-01-2012
Added/Updated Jan 31 2012
RE: BPI + Authentication Explained by ABMJR - crazyanimal - 06-02-2012
if i get to a point where i need to stop asking this in public please delete and pm me, if you don't mind.
So this is why i get 2 sets of certs when i pull from the nonvol? now i have not opened them yet, as i have been on the xbox and spending time with the wife more
lol, to see if they differ other than hitting them in hxd compare and seeing a big difference in code. how do you tell them apart for which is cvc and mfg? good write up ABMJR, i just need to read it 3 more times and take it all in.+1 for ya also
RE: BPI + Authentication Explained by ABMJR - drewmerc - 06-02-2012
normally there is no difference between the 2 sets
RE: BPI + Authentication Explained by ABMJR - crazyanimal - 06-02-2012
thats weird . i did a compare in hxd and the 2 bins i looked at (i forgot which ones i used) were way different. maybe i can post them up when i get home. i'll make sure my mac isn't in them lol.
RE: BPI + Authentication Explained by ABMJR - crazyanimal - 07-02-2012
these came out of the modem using cmnon at the same time in one scan. there are 2 of every file, public,private,root cm,ca. it is a d3 modem, if that matters
RE: BPI + Authentication Explained by ABMJR - Al_n Monday - 08-02-2012
Keep testing
RE: BPI + Authentication Explained by ABMJR - crazyanimal - 09-02-2012
Ill never stop lol. Its to damn addictive
RE: BPI + Authentication Explained by ABMJR - andytx - 12-04-2012
how to change Sb6120 BPI 1.0 to 1.1?