-
Notifications
You must be signed in to change notification settings - Fork 13
NDNCERT Intra Node
Intra-node NDNCERT was designed to provide trust management between local NDNCERT CA daemon and applications running on the same node. Intra-node NDNCERT mainly contains:
- Local available CA probing
- Two-way security challenge
Compared with inter-node case, there is no _VALIDATE, _STATUS The _SELECT step requires user input from the application.
certificate requester CA
| /localhost/CA/LIST |
| --------------------------------> |
| |
| |
| All available CAs |
| <-------------------------------- |
| |
Select one CA |
| _PROBE (app name) |
| --------------------------------> |
| |
| Assign an available namespace
| Data |
| <-------------------------------- |
| |
Generate key pair |
Generate certificate request |
| |
| _NEW |
| --------------------------------> |
| |
| Store request instance and Generate request ID
| Generate a PIN code and appears on the window of NDNCERT CA
| |
| Data |
| <-------------------------------- |
| |
Requester types in the code from app |
| |
| _SELECT (with encrypted code) |
| --------------------------------> |
| |
| Code is right, issue cert
| if wrong, abort
| _DOWNLOAD |
| --------------------------------> |
| Data |
| <-------------------------------- |
Local application instance can send interest to local NDNCERT CA daemon to get all available CAs. The interest packet name is fixed for now:
Interest: /localhost/CA/LIST
CA registers the prefix /localhost/CA/LIST
when starts. Whenever CA receives the interest packet. CA would collect all the available CAs and generate a json in NDNCERT client configuration format and reply.
The data packet is signed by the CA using the default key of the local KeyChain. The json format of the data packet is the same as the client configuration, which is like:
{
"ca-list":
[
{
"ca-prefix": "/ndn/edu/ucla/CA",
"ca-info": "UCLA's ceritificate authority, located in BH4805.",
"probe": "Please use your email address to apply a namespace first. UCLA email is preferred.",
"supported-challenges":
[
{ "type": "PIN" },
{ "type": "EMAIL" }
]
},
{
"ca-prefix": "/ndn/edu/ucla/zhiyi/CA",
"ca-info": "Zhiyi's own ceritificate authority",
"supported-challenges":
[
{ "type": "PIN" }
]
}
]
}
The two-way PIN challenge is specifically designed to automate intra-node trust decision. This challenge allows users to ensure that the certificate request is coming from a legitimate application (NDNCERT CA veries that an application is signed by a trusted developer) and from the correct instance of the application through (visual) matching of the PIN code generated by the application and shown in the CA