Re: [SG2] APFCs in Stargrunt

Thomas spake thusly upon matters weighty: 

> the IFF scanner sends out an interrogation ping, including its own id,
a
> challenge sequence (different every time) and the challenge sequence
> encrypted with its own private key. since all IFF units have a
registry of
> all public keys,

In a large organization, PKI management becomes problematic. The 
national police here are wrestling with this nightmare now. 

> thus, before an IFF tag says anything, it makes sure the scanner is
> legitimate, and not an enemy EW unit. security is provide by using
very
> long cipher keys.

Too slow potentially. Long keys take time to exchange. And if the key 
exchange takes a few transactions (I've seen up to six), that 
translates to a speed you don't want to think of on the battlefield 
(you'll get nuked while this is processing or slow your guns down a 
bunch to carry this out), even if you do use GHz range transmitters 
(which is like installing a microwave in the back of your head... no 
risk of cancer though!).

I work with 800 band comms and they still are no blistering heck. 
Doing even private key crypto over them is potentially quite an 
overhead. Public key crypto is a brutal thought. Yes, it is far in 
the future, but if you plan to put it into someone's head, you'll 
want it to be a very low level digital signal, and you have some 
profound limitations on data rate as a function of range and power. 
And if you get down to that level, it begins to be possible for low 
power jamming to take out your signal easily. Of course, various 
error corrections schemes oppose this, but you could be blocked 
getting channel access, etc. 

I've worked on public and private radio networks (non-military) and 
have talked with comms security gurus (military and intel 
backgroun) and have some idea that what you say is possible, but 
might not be fast enough. And their may be denial attacks that work 
against it. Cracking it is hard. Making your IFF non-functional may 
be easier. 

> for bonus security, the challenge sequence would include a timestamp,
to
> protect against 'playback' attacks where the enemy records  an IFF
> challenge and plays it back to stimulate and IFF tag. all IFF units
would
> need synchronised time - this can be got from the GPS system. also,
the
> scanner's id should be attached to the tag's message, so that multiple
> simultaneous scans do not interfere.

...slower yet....

and simultaneous scans suggests using multiple frequencies - 
otherwise you'll get collisions on the channel. Or timeslicing. Any 
way you look at it, RF limits your data rate. As data rate climbs, 
range declines. (I think something like range declines as a function 
of the square of the increase in data rate - doubling data rate cuts 
range by a factor of 4 - but I could be wrong0.  

> </geek:crypto>

> the message would include info on the wearer - whether he is alive or
> dead, for instance. the mainframe's security manager would not allow
> access by dead users.

Great. So your health monitor breaks and you can't comm for the arty 
support. Joy.  There'd still have to be a manual human-verified 
backup system.
 
> the thing with IFF is that, unless your tag has a directional emitter,
the
> enemy will be able to pick up the replies your tag makes to scans.

And how do you do a subcutaneous directional transmitter? 

 if
> these are infrequent (eg only when a scanner notices a new potential
> target), or if the reply is made with low-frequency frequency-agile
radio,
> etc, then it is not too bad.

But it still could be detected. The only 100% security is not to 
encode anything. And the only 100% non-detection is not to use your 
comms. 
 
Tom.  
/************************************************
Thomas Barclay		     
Voice: (613) 831-2018 x 4009
Fax: (613) 831-8255

 "C makes it easy to shoot yourself in the foot.  C++ makes
 it harder, but when you do, it blows away your whole leg."
 -Bjarne Stroustrup
**************************************************/