Re: Use of tokens for access to Debian resources?
On Wed, Nov 15, 2006 at 08:32:10AM +1100, Hamish Moffatt wrote:
> On Tue, Nov 14, 2006 at 06:47:57PM +0100, Sven Luther wrote:
> > On Tue, Nov 14, 2006 at 06:38:58PM +0100, Marco d'Itri wrote:
> > > apollock@debian.org wrote:
> > >
> > > >I'm inclined to agree with Russell Coker[1], in that Debian should use
> > > >something like RSA tokens to control access to Debian resources.
> > > I'd love to, but I do not know any which is even close to be really
> > > free-as-in-freedom.
> >
> > They should be trivial to produce though, if there was a budget for it,
> > especially given the relatively big amount of cash debian has on the spi bank
> > accounts.
> >
> > A special kind of token designed for our uses, with an optional braille
> > display for example. Done as a open-source hardware project, with open source
> > hardware design tools. That would be a worthy project, and the open sourceness
> > of it could both be an example of open source hardware, and improve the
> > computer security generally.
>
> I don't think they would be trivial to replicate. The genuine RSA token is a
> small sealed card with a keypad, a display and a battery that lasts up
> to 3 years. They are small so as to be portable and convenient, which DDs
> will demand.
Well, the important thing is to replicate the functionality, or to implement
something different which is suited to the method we want to use. We are going
to decide how both sides of the process work, so we can adapt it to the
possibilities, and i beliee we have enough technical competences about
cryptography in debian that we could come up with something nice. I don't have
such knowledge myself though, but i have an interrest in electronics, and some
basic knowledge.
> I don't think the electronics is complicated; basically it just has a
> seed which increments every 60 seconds exactly, and to use it you key in
> your PIN. Some function of your PIN + the current seed makes your
Indeed. This is pretty trivial. We would like to replace the display by a
braille display for example.
> temporary password. The difficulty is in manufacturing something small
> and reliable.
Well, small is not very problematic, the thing is that it has to be rather
economic. Reliability is also important, but none of those are really
extremely difficuly things.
> The 60 second update does need to be accurate over the 3 year lifetime,
> because a software process at the other end has to know the current
> seed. (Often there is +/- one seed leeway). That over extremes of heat,
> cold, humidity etc which affect clock stability.
Yes, this is probably the most complicated part of the design, but as said we
can adapt the protocol a bit to handle less accurate clocks.
I know that standard RTC chips, with temperature compensations, can reach
accuraccies of 2 ppm (0-40 dgree) and upto 3.5ppm (-40 - 85 degrees), but
maybe something else can be used. 2ppm correspond to roughly a minute every
year or so, so this would be too much for the 60s max delay over 3 years,
since it would be 3 seeds at the end of the 3 year period. Not so bad though.
That said, there is another factor that may help. Even losely accurate quartz,
as those used in common clocks, can obtain a greater amount of accuracy by
keeping them at a constant temperature, namely at body temperature. I am not
sure folk would like watch-like tokens though :)
BTW, i didn't know humidity affected the clock stability, but i guess that in
a ruggedized setup, humidity should not be a problem, no ?
Friendly,
Sven Luther
>
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
>
>
> --
> To UNSUBSCRIBE, email to debian-project-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
> ---------------------------------------------------------------------------------------
> Orange vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
Reply to: