Custom Security Dongle: Difference between revisions

From NewEagleWiki
Jump to navigation Jump to search
(Created page with 'Custom security keys limit the ability to calibrate and interact with your modules to only those individuals that have the keys installed on their silver tokens. Within the appli…')
 
No edit summary
Line 9: Line 9:
The custom security keys are designed to limit and authorize MotoTune interactions with the system. If the CCP interface is being used, security functions and distribution mechanisms will need to be added for the PC authentication.  
The custom security keys are designed to limit and authorize MotoTune interactions with the system. If the CCP interface is being used, security functions and distribution mechanisms will need to be added for the PC authentication.  
   
   
No matter what keys are in the module, the chip is always censored, preventing BDm or JTAG access at the board level, thus stealing code via mechanism is relatively secure. The SRZ files containing the application and calibrations are also encrypted meaning only MotoTune can open them for programming. MotoTune cannot create an unencrypted version of the file; the only time the memory in=mage is ever visible is during programming across the CAN bus. While it is possible to detect the CAN bus and record the programming transaction, it is impossible to attempt to modify the trace and reprogram the module by relaying the trace as the initial authentication request changes each time requiring the aforementioned security keys to compute the challange.
No matter what keys are in the module, the chip is always censored, preventing BDm or JTAG access at the board level, thus stealing code via mechanism is relatively secure. The SRZ files containing the application and calibrations are also encrypted meaning only MotoTune can open them for programming. MotoTune cannot create an unencrypted version of the file; the only time the memory image is ever visible is during programming across the CAN bus. While it is possible to detect the CAN bus and record the programming transaction, it is impossible to attempt to modify the trace and reprogram the module by relaying the trace as the initial authentication request changes each time requiring the aforementioned security keys to compute the challange.
   
   
Creating a set of keys and managing the whereabouts of the provisioned security tokens is the mechanism that is available.
Creating a set of keys and managing the whereabouts of the provisioned security tokens is the mechanism that is available.
   
   
[[Image:SecurityDongle1.JPG]]
[[Image:SecurityDongle1.JPG]]

Revision as of 17:15, 10 June 2010

Custom security keys limit the ability to calibrate and interact with your modules to only those individuals that have the keys installed on their silver tokens. Within the application, each calibration, probe and table has the ability to set four read and write access levels. The custom keys contain 4 key sets associated with each of the access levels. The policy level of each level and assignment of each access level can be controlled. An example of the four levels can be seen as follows:
4: Engineering
3: Factory
2: Dealer
1: Customer
Each access level can be adjusted depending on what usage seems appropriate. In the above example, the "Dealer token has level 2 privileges and programming privileges while a "Customer" token only has level 1 keys without programming capability.

The custom security keys are designed to limit and authorize MotoTune interactions with the system. If the CCP interface is being used, security functions and distribution mechanisms will need to be added for the PC authentication.

No matter what keys are in the module, the chip is always censored, preventing BDm or JTAG access at the board level, thus stealing code via mechanism is relatively secure. The SRZ files containing the application and calibrations are also encrypted meaning only MotoTune can open them for programming. MotoTune cannot create an unencrypted version of the file; the only time the memory image is ever visible is during programming across the CAN bus. While it is possible to detect the CAN bus and record the programming transaction, it is impossible to attempt to modify the trace and reprogram the module by relaying the trace as the initial authentication request changes each time requiring the aforementioned security keys to compute the challange.

Creating a set of keys and managing the whereabouts of the provisioned security tokens is the mechanism that is available.