summaryrefslogtreecommitdiff
path: root/cesar/mac/common/config.h
AgeCommit message (Collapse)Author
2013-05-23cesar/{bsu,cp,mac/pbproc}: change NEK managementYacine Belkadi
Two slots were used to store the NEKs. One for the current NEK, the other for the next NEK. The CP could update any slot at any time, by setting the EKS to MAC_EKS_CLEAR first. One problem is that the pbproc doesn't expect someone to change a key that it is in use. If the cp sets the EKS to MAC_EKS_CLEAR for a key that is in use, may make the pbproc send data unencrypted, which is a problem. Another problem may occur during a NEK change, if the new NEK is not received via the SET_KEY_CNF. In that case, when the countdown starts, the cp sends a GET_KEY_CNF to get the new NEK. When it receives it, it puts the new key in the next slot. To identify the next slot the cp uses bsu_nek_index_next(). This is not reliable around a NEK change: - the cp receives the new NEK - the cp starts setting the new NEK - the cp is suspended - the bsu changes nek_switch - the cp is resumed and calls bsu_nek_index_next() which returns the index of the current NEK instead of the next NEK - the cp writes the new NEK in the current slot instead of the next slot - the pbproc may send packets unencrypted - the NEK change occurs - the new NEK is used in Rx (because the new NEK is in one of the two slots) but not in Tx (because it's not the in the current slot) To fix that, change the way the NEKs are managed: Use pointers and indirection to be able to atomically change a NEK transparently from the pbproc's point of view. Make the cp store the NEKs and set the current NEK, but let the bsu grab the next NEK if it's available.
2008-12-12 * mac/common:schodet
- added default TEI for partial acknoledge. git-svn-id: svn+ssh://pessac/svn/cesar/trunk@3639 017c9cb6-072f-447c-8318-d5b54f68fe89
2008-06-09 * mac/ca, mac/pbproc, mac/common:schodet
- moved SNID to CA schedule, closes #75. git-svn-id: svn+ssh://pessac/svn/cesar/trunk@2253 017c9cb6-072f-447c-8318-d5b54f68fe89
2008-04-07Moved the complete svn base into the cesar directory.save
git-svn-id: svn+ssh://pessac/svn/cesar/trunk@1769 017c9cb6-072f-447c-8318-d5b54f68fe89