Re: One-sided authentication for small micros?
From: Michael Amling (nospam_at_nospam.com)
Date: 10/18/03
- Next message: Richard Heathfield: "Re: New software featuring GEM 1024 bit encryption engine."
- Previous message: Michael Amling: "Re: WHY TO GO BERNSTEIN"
- In reply to: Matthue Gera: "Re: One-sided authentication for small micros?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 18 Oct 2003 17:03:51 GMT
Matthue Gera wrote:
> Some thoughts on your problem.
>
> What about if you have a unique id in each slave.
>
> The master has a lookup table of all 'known' slave id's.
>
> The master sends out a broadcast every x second asking the slaves to indentify
> themselves. Or maybe just at startup time of the master.
> This would reset all the slave keys to their lookup values.
>
> Only slaves replying with valid id's (within the master table) are considered
> valid. id's are seen and keys are not.
>
> Now you have a situation where anything else on the network can read those response
> but they do not know which are considered 'valid' by the master as the master does
> not respond to say 'you are ok' etc.
>
> The only problem here is that if a hack slave tried to use any of those id's are
> keys to communicate with the master illegally.
>
> You could solve this by having a master lookup table of id's which are used
> for broadcasting authentication purposes only. (sent to the master upon the master
> broadcasting a request to the slaves for identifcation.
>
> When the master find a valid slave id responding back, it uses a second id as the
> encryption key when communicating with that slave.
>
> The slave also has a second id which is used for the key whenever the master
> decides that it is a valid slave and starts to communicate with the slave.
>
> To make it more secure you could mix another key with the second key stored in the
> masters second lookup table and the slaves second lookup table used for the key.
>
> Whenever the master and slave successfully finish a valid packet request/packet
> response the master and slave use another key generator and change the key with
> every packet sent and acknowledged.
>
> The security here is based on hackers not being able to find out the lookup id's
> and keys of either of the master/slaves. So I assume only the cable which the
> communications is used is insecure and the slaves and masters cannot be physically
> got at. This solves your lookup insecurity problem. And as long as nobody
> gives out those lookup tables, any other types of illegal slaves will be ignored
> and they will not be able to look at any data being passed between slaves and masters
> because they do not have to keys used for the packet encryption.
> And also they do not know how the keys will be generated for future packets.
>
> You could also add a global variable to this key re-generation to further
> formulate future keys for master/slave communications but this opens up another
> insecurity if the global variable is derived from outside of the security of the
> masters and slaves themselves.
>
> The above method should work for you if you do not require encryption that is
> too complex, it sounds like you want something which is easy and would take allot
> more than normal effort to try to hack/crack.
>
> Passing startup keys between masters and slaves is a bad idea as any other illegal
> slave can listen to them being sent and decide to use one if it can decide the
> identity of the slave it wants to kidnap.
>
> A id/key lookup method would ultimately be okay for this.
>
> Ultimately just make sure the lookup tables (keys not ids) themselves are not
> transmitted to one another in their raw state otherwise as said before they
> could be hyjacked by a alien and nasty slave.
I can only assume this is an example of the type of thinking that
went into GEM 2003.
--Mike Amling
- Next message: Richard Heathfield: "Re: New software featuring GEM 1024 bit encryption engine."
- Previous message: Michael Amling: "Re: WHY TO GO BERNSTEIN"
- In reply to: Matthue Gera: "Re: One-sided authentication for small micros?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
