turn power on.
This equals to INIT
After that Initialise is done and new RSA keypair is generated
waiting for input priv_fnc_cnt
input priv_fnc_cnt
input moduli size
the last is the size of modular exponent calculations and can be from 192 to 1500.If you are afraid to mess things up or if you want more than 1 partners put here up to 0xFFFF. It is of course security hole, but you can and should check all PK key fields to make sure no-one has changed them
Now you must use PUBO or ADDNEW
PUBO output current RSA public key
get it from chip from every chip
ADDNEW - add new users
Now you should form the authentic data fields of public keys. For that you present chip with Public key of future partner. Beware, that priv_fnc_cntis decremented each time you use ADDNEW and when it reaches 0 you will have to re-initialise chip to add new partners. After each cycle store public key authentic field. If there is only one partner then priv_fnc_cntis 0 and info is kept inside chip. Otherwise it could be saved locally in on-board RAM, but nothing is wrong with having it in database. It is not chips business, but later you must provide the correct data field when required.
ADDNEW or other command
Upon exit you can and should verify all fields using chips public key. You should see something like that after decrypting authentic PK field (APKF) with CCs public key: [ (Control field), Binary Public key of partner).
you MUST repeat it with all chips you are planning to use. After all is done you are ready to start to communicate. What remains is to generate idea key and change it.
IDGEN generate IDEA key and take it into use.
waiting for command...
IDOUT output RSA encrypted current idea key.
waiting for command...
Now you must send this information among with the id of sender to partner with whom you want to communicate. He/she/it after receiving such request sends her/his/its output of IDOUT to you. Now you must feed chip with correct APKF generated previously and data from IDOUT of her/its/his chip.
IDIN input RSA encrypted IDEA key.
waiting for command....
After chip responds with OK we are set up. If it is not OK, there may be data transfer error, or not correct Public key field. If it is link error, then it is up to lower level protocol to handle that. If it is PK difference then you might have given wrong field or that may be wrong chip trying to get into contact. It is up to you to retry or whatever. IF result is OK you are set up for encryption (Assuming the same with partner) You are now free to use
IDENC, IDDEC to IDEA EN/DECRYPT
waiting for command....
It is pretty straightforward how to change session key for idea, but suppose you want to change the RSA key. First you must use function EXGEN to generate new RSA keypair
waiting for command.....
EXGEN - generate new RSA keypair.
New keypair is generated, and all APKFs must be presented to CHIP before exit If you fail to update some APKFs then they are gone forever. This feature can be used to delete nodes.
After exit all PK fields from memory when requested are deciphered using new key. Also, all requests of key exchange are encrypted using new RSA key. All you can to do now is to notice others that you want to change RSA keys. That can be done with command 5- output RSA public new encrypted with RSA current key and on the other side Input RSA public.
waiting for command.....
EXOUT - output RSA new key encrypted with RSA old
The output MUST be sent to all partners. Al the partners use EXIN to check and upon positive result update APKF. After having affirmative answers from all you must use USENEWEX
waiting for command...
USENEWEX take new RSA keypair into use
Now we have updated Both keys and used IDEA for EN/Decryption.
One last thing remains to be explained: it is updating network configuration.
There is problem when adding users. Because encryption is done transparently all network members are 'trusted hosts', meaning they have no secrets from each other. Therefore it is pretty much clear that you should not be able to add new nodes easily and unnoticed. For testing that CC has internal counter called priv_fnc_cnt, what is evaluated after reset. This is the amount of times you can use node additions. Therefore it is important to plan nodes correctly. This number is part of APKF and can be checked any time. If you are sure you do not want to add more nodes you can reset this counter with external command. Suppose you are checking these fields and are very right person doing very right thing and still have new node to attach . You initiate the procedure with ADDNEW
waiting for command....
ADDNEW Encipher. with current secret key and create new PK record
This command outputs new PK record until priv_fnc_cnt= 0. if that happens you cannot use this command until new restart. From this point on you have the possibility to use ADDNEW until priv_fnc_cnt=0 or exit
Upon exit you are thrown into RSA key change as explained previously
As RSA keypair changes happen not_so_veryoften all these, who are in contact with you will receive notice from you that keys are changed and after that can come together for lunch and compare their respective public keys to make sure no forgery has happened.. With 1024 (max.1500) bit keys used only for session keys encryption this is not going to happen in every 2 weeks, not even in every 2 months. Therefore the most primitive way to control it is to keep chipcard or whatever with old PK of your chip in that. Before initiating communications you compare PKs of chip or try to decrypt some PK data fields. If it does not work and you have not initiated RSA key change yourself that's it . Someone has been tampering with database. RSA keypair changes should be initiated by only user. But it is organisations problem and not chips business. You can have a bell on the wall ringing when RSA key change is appearing, stop all communications and call the person who did it.
IDEA key generation and updating can be done transparently. That still does not mean we do not need the priv_fnc_cntregister. If you have stable net - like point-to point line and you are not planning to go to the other end for a long time you can after all is set up zero the register with ZERCNTand have your conscience clean - no-one, not even yourself can add new components (even if they somehow manage to fake The PK database for you). The APKF field contains also additional information to avoid re-using of old keys, but these are technical details.
As for OUTRND, you might want paranoid as you might be test the RND generator all the time and find out the dependencies. But then You might just need physical RND generator for other tasks.