Re: "secure" file flag?

From: Devon H.O'Dell (dodell_at_sitetronics.com)
Date: 11/28/03

  • Next message: Daniel Eischen: "Re: support for __thread"
    Date: Fri, 28 Nov 2003 09:34:50 +0100
    To: Wes Peters <wes@softweyr.com>
    
    

    > If you want an interesting problem to work on, come up with a solution
    > to
    > the keying problem for disk encryption. It somehow needs to allow
    > automated, unattended reboots during "normal" operations but prevent
    > attackers from compromising the system. Maybe you could have the
    > system
    > send an SMS message when it needs a key, you reply with a one-time key
    > from your mobile phone?

    Actually, this is quite similar to what people at Vasco do
    (http://www.vasco.com). They make devices that (from what I can tell)
    hash a PIN and a timestamp (along with some other arbitrary values
    generated by a server, which are optional) and give you a return hash.
     From what I've seen, the hash is rather elementary and I feel somewhat
    silly using it to log into my bank. I sent an email to them a while
    ago; it seems that the security may lie somewhat on the knowledge of
    the hashing function.

    But there are definitely devices that do these sorts of things
    (although the ones from Vasco don't work with GSM, so sending the SMS
    back would have to go through the phone). Although, I must say, that
    sending the SMS via the phone is quite insecure as well. If you've the
    ability to send SMSes, you can most likely fake the address your SMS is
    coming from, just like you can fake an email. Although, AFAIK, it's a
    bit more difficult to track the origin of an SMS message.

    However, most new phones have J2ME capability. I hate Java, but since
    it's the HLL that we're allowed to use, we could make use of it. After
    Helix has had some time to be cryptanalyzed, it might be a good
    candidate for just this kind of application -- a lightweight, fast,
    easily implementable encryption and authentication algorithm (though it
    looks promising to me). Until then, some other kind of
    encryption/authentication could take place. In any case, many phones
    allow sockets to be created and sent (and if they don't, they most
    certainly support HTTPS channels). I think an app utilizing this would
    be a bit more secure in this scenario than one via SMS (or via the
    Vasco method, I don't have a ton of faith in their closed-source
    solution). This would be a good, mobile way to provide a one-time key,
    though. You might even be able to implement it to request keys from
    multiple administrators assuming the first administrator failed. Who
    knows.

    Haven't been following this discussing very closely, so feel free to
    poke me with a stick if I'm babbling about some obscure tangent.

    > While you're in there, paint that bikeshed blue.

    Only if there's not someone painting it already :)

    > --
    >
    > Where am I, and what am I doing in this handbasket?
    >
    > Wes Peters
    > wes@softweyr.com

    --Devon

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  • Next message: Daniel Eischen: "Re: support for __thread"

    Relevant Pages

    • RE: Encryption & SMS
      ... I waiting toi here back from IBM on the cost of: IBM DFSMSdss Encryption ... Of Dean Montevago ... Subject: Encryption & SMS ...
      (bit.listserv.ibm-main)
    • Encryption & SMS
      ... I received a note mentioning a vendor is developing an encryptrion ... need to check the SMS ACS to determine which encryption method to use." ... SMS -vs- non-SMS. ... For IBM-MAIN subscribe / signoff / archive access instructions, ...
      (bit.listserv.ibm-main)
    • Re: un-hashing to reveal pass phrase [was: crypto sms]
      ... > What problem does not having a public key solve? ... If you send an SMS, ... > text then obviously you have used encryption. ...
      (sci.crypt)