Loading ...
Sorry, an error occurred while loading the content.

Authentication

Expand Messages
  • Jon
    As I m running away (for zzz s) and you guys have some hours left in the day yet, I was wondering if you had thought much about an authentication mechanism
    Message 1 of 8 , Apr 12, 2006
    • 0 Attachment
      As I'm running away (for zzz's) and you guys have
      some hours left in the day yet, I was wondering if you
      had thought much about an authentication mechanism
      yet?

      Nite!

      de John
      EI7IG


      Send instant messages to your online friends http://uk.messenger.yahoo.com
    • scott@opentrac.org
      I posted on the APRS SIG about this the other day. I m thinking three different schemes would be useful: 1: Callsign only 2: Simple scheme you can do in your
      Message 2 of 8 , Apr 17, 2006
      • 0 Attachment
        I posted on the APRS SIG about this the other day. I'm thinking three
        different schemes would be useful:

        1: Callsign only
        2: Simple scheme you can do in your head or with pencil and paper
        3: True MAC

        1 is already implemented, you just can't add anyone else to the access list
        yet. 2 would be like the KPC-3 RTEXT scheme, only it'd need to be stronger
        than that - every command you send is going to be archived forever, easily
        accessible by anyone who wants to figure out your code.

        3 is going to require client software support. The actualy message
        authentication code will most likely be based on TEA (a strong but very
        compact block cipher) running in a cipher block chaining (CBC-MAC) mode
        variant like OMAC-1.

        I've already got the TEA encryption and decryption code ready. It's very
        lightweight and suitable for implementation in an 8-bit micro. It's not as
        strong as AES or 3DES, but there's not much point in going with a stronger
        algorithm. If someone's really that determined to mess with your equipment,
        you've got other problems.

        Number 2 is what really needs some thought. Kantronics uses a scheme like
        this: You pick a passphrase, for example:

        RTEXT OpenTracker2

        When you connect, it presents a challenge asking for (if I recall) six
        random characters of the passphrase. You get three challeneges to choose
        from, so it's not supposed to be obvious to an eavesdropper which one you're
        answering. The challenges might look like this (yes, I'm a big enough geek
        to have a 12-sided die handy):

        9 6 11 12 8 7
        5 8 6 1 9 11
        8 9 11 8 6 10

        Let's say I pick the middle one. The corresponding letters are 'TcrOkr'.
        Secure enough if you don't use it very often, but for APRS use you'd very
        quickly expose your entire passphrase.

        An alternative used by another APRS application is a numeric code. The code
        starts at a known value at a certain time of day, and is incremented or
        decremented by a specified value every so many minutes. It can also be
        incremented or decremented with each transmission. You can (in theory) keep
        track of this in your head, but it gets complicated unless you're using very
        simple settings. And even more complicated settings aren't going to be hard
        for an attacker to figure out if they get enough examples to work from.

        Ideally, we want something that can be used with a 1-way link. Maybe you
        accidentally powered off the transmitter and need to turn it back on, or
        maybe it's a runaway balloon that you need to send a cutdown command but you
        can't hear its 100 mW transmitter. The trouble with this is that there's no
        way to do a challenge/response scheme, which makes it harder to prevent
        replay attacks, where someone just resends what they know is a valid code.

        The device might not have a GPS receiver, so that precludes time-of-day
        based schemes. One-time codes are a possibility - I used to carry around a
        pre-printed list of codes in my wallet for times when I needed to access a
        remote system from an unsecured network. Again, if it's a 1-way link, it's
        more complicated because you don't know which code the system is expecting,
        and it might have to be able to accept them in any order and keep track of
        which individual codes have been used.

        If anyone has suggestions for an algorithm, let me know...

        Scott


        > -----Original Message-----
        > From: tracker2@yahoogroups.com
        > [mailto:tracker2@yahoogroups.com] On Behalf Of Jon
        > Sent: Wednesday, April 12, 2006 2:50 PM
        > To: tracker2@yahoogroups.com
        > Subject: [tracker2] Authentication
        >
        > As I'm running away (for zzz's) and you guys have
        > some hours left in the day yet, I was wondering if you
        > had thought much about an authentication mechanism
        > yet?
        >
        > Nite!
        >
        > de John
        > EI7IG
        >
        >
        > Send instant messages to your online friends
        > http://uk.messenger.yahoo.com
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        >
        >
      • Patrick Gardella
        One option you have is to use what used to be called S/Key, and is now known as One Time Passwords in Everything (Opie). The basic idea is that it is a
        Message 3 of 8 , Apr 18, 2006
        • 0 Attachment
          One option you have is to use what used to be called S/Key, and is now known as One Time Passwords
          in Everything (Opie). The basic idea is that it is a challenge/response authentication. It gives
          you a counter value, and your seed, and you use a calculator,with your secret key, to generate a
          one time password. You then send that particular password to the system. It uses MD5. You don't
          need to keep a list of one time passwords, although you could. I'm not sure you can make this fit
          on your processor though.

          A good walkthrough of an existing system:
          http://www.onlamp.com/pub/a/bsd/2003/02/06/FreeBSD_Basics.html

          Overviews:
          http://www.deer-run.com/~hal/ns2000/otp.pdf
          http://www.surfnet.nl/innovatie/surf-ace/security/doc/skey.html

          Code samples:
          http://www.inner.org/opie

          You still have the one-way link problem, but you could eliminate that by using a regular password
          as well. You use OPIE all the time normally, or you could just type in your password.

          73,
          Patrick N3EO

          --- scott@... wrote:

          > I posted on the APRS SIG about this the other day. I'm thinking three
          > different schemes would be useful:
          >
          > 1: Callsign only
          > 2: Simple scheme you can do in your head or with pencil and paper
          > 3: True MAC
          >
          > 1 is already implemented, you just can't add anyone else to the access list
          > yet. 2 would be like the KPC-3 RTEXT scheme, only it'd need to be stronger
          > than that - every command you send is going to be archived forever, easily
          > accessible by anyone who wants to figure out your code.
          >
          > 3 is going to require client software support. The actualy message
          > authentication code will most likely be based on TEA (a strong but very
          > compact block cipher) running in a cipher block chaining (CBC-MAC) mode
          > variant like OMAC-1.
          >
          > I've already got the TEA encryption and decryption code ready. It's very
          > lightweight and suitable for implementation in an 8-bit micro. It's not as
          > strong as AES or 3DES, but there's not much point in going with a stronger
          > algorithm. If someone's really that determined to mess with your equipment,
          > you've got other problems.
          >
          > Number 2 is what really needs some thought. Kantronics uses a scheme like
          > this: You pick a passphrase, for example:
          >
          > RTEXT OpenTracker2
          >
          > When you connect, it presents a challenge asking for (if I recall) six
          > random characters of the passphrase. You get three challeneges to choose
          > from, so it's not supposed to be obvious to an eavesdropper which one you're
          > answering. The challenges might look like this (yes, I'm a big enough geek
          > to have a 12-sided die handy):
          >
          > 9 6 11 12 8 7
          > 5 8 6 1 9 11
          > 8 9 11 8 6 10
          >
          > Let's say I pick the middle one. The corresponding letters are 'TcrOkr'.
          > Secure enough if you don't use it very often, but for APRS use you'd very
          > quickly expose your entire passphrase.
          >
          > An alternative used by another APRS application is a numeric code. The code
          > starts at a known value at a certain time of day, and is incremented or
          > decremented by a specified value every so many minutes. It can also be
          > incremented or decremented with each transmission. You can (in theory) keep
          > track of this in your head, but it gets complicated unless you're using very
          > simple settings. And even more complicated settings aren't going to be hard
          > for an attacker to figure out if they get enough examples to work from.
          >
          > Ideally, we want something that can be used with a 1-way link. Maybe you
          > accidentally powered off the transmitter and need to turn it back on, or
          > maybe it's a runaway balloon that you need to send a cutdown command but you
          > can't hear its 100 mW transmitter. The trouble with this is that there's no
          > way to do a challenge/response scheme, which makes it harder to prevent
          > replay attacks, where someone just resends what they know is a valid code.
          >
          > The device might not have a GPS receiver, so that precludes time-of-day
          > based schemes. One-time codes are a possibility - I used to carry around a
          > pre-printed list of codes in my wallet for times when I needed to access a
          > remote system from an unsecured network. Again, if it's a 1-way link, it's
          > more complicated because you don't know which code the system is expecting,
          > and it might have to be able to accept them in any order and keep track of
          > which individual codes have been used.
          >
          > If anyone has suggestions for an algorithm, let me know...
          >
          > Scott
          >
          >
          > > -----Original Message-----
          > > From: tracker2@yahoogroups.com
          > > [mailto:tracker2@yahoogroups.com] On Behalf Of Jon
          > > Sent: Wednesday, April 12, 2006 2:50 PM
          > > To: tracker2@yahoogroups.com
          > > Subject: [tracker2] Authentication
          > >
          > > As I'm running away (for zzz's) and you guys have
          > > some hours left in the day yet, I was wondering if you
          > > had thought much about an authentication mechanism
          > > yet?
          > >
          > > Nite!
          > >
          > > de John
          > > EI7IG
          > >
          > >
          > > Send instant messages to your online friends
          > > http://uk.messenger.yahoo.com
          > >
          > >
          > >
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          >
          >
          >
          >


          __________________________________________________
          Do You Yahoo!?
          Tired of spam? Yahoo! Mail has the best spam protection around
          http://mail.yahoo.com
        • David and Ann Fraser
          ... One variant of the common scheme is where the response to the five number challenge is embedded in a long string. For example, if you were meant to respond
          Message 4 of 8 , Apr 19, 2006
          • 0 Attachment
            > From: <scott@...>

            > If anyone has suggestions for an algorithm, let me know...

            One variant of the common scheme is where the response to the five
            number challenge is embedded in a long string. For example, if you were
            meant to respond "abcde" you would actually respond "zgjklijtabcdepoijf"
            or an even longer string, but still with the proper response inside it.

            This makes it far harder for eavesdroppers to determine what your
            passphrase is, yet you can easily work out what your response is.

            (I hope that was clear - it's been a long day)

            David ZL3AI
          • scott@opentrac.org
            Still way behind on my email... ... The same system could be used with another hash besides MD5. TEA would probably work. ... Using a regular password without
            Message 5 of 8 , Apr 26, 2006
            • 0 Attachment
              Still way behind on my email...

              > one time password. You then send that particular password to
              > the system. It uses MD5. You don't
              > need to keep a list of one time passwords, although you
              > could. I'm not sure you can make this fit
              > on your processor though.

              The same system could be used with another hash besides MD5. TEA would
              probably work.

              > You still have the one-way link problem, but you could
              > eliminate that by using a regular password
              > as well. You use OPIE all the time normally, or you could
              > just type in your password.

              Using a regular password without some sort of challenge still leaves you
              vulnerable to replay attacks. It might be sufficient to keep track of which
              passwords have been used (on the device itself), and in a pinch you could
              just skip a few and guess.

              If the used-challenge data is tracked in flash, it adds some wear issues.
              If an entire page of flash (512 bytes) is set aside, you can avoid that to
              some extent by doing successive writes to the same page until it's filled
              up. Hmm.. actually, it might be possible to do successive writes to the
              same byte, though you'd only be able to change 1's to 0's. In any case,
              that'd greatly reduce the number of erase cycles needed, but it'd still eat
              a whole page. Might be easier to justify if there are other parameters that
              need to be frequently updated as well.

              Scott
            • juha.nurmela@quicknet.inet.fi
              ... You could use the 512-byte page (or less) as 4096 bits, each corresponding to, say, 1024. Or whatever is easiest to work with shifts/ands. Then every time
              Message 6 of 8 , Apr 27, 2006
              • 0 Attachment
                On Wed, 26 Apr 2006 scott@... wrote:

                > same byte, though you'd only be able to change 1's to 0's. In any case,
                > that'd greatly reduce the number of erase cycles needed, but it'd still eat
                > a whole page. Might be easier to justify if there are other parameters that

                You could use the 512-byte page (or less) as 4096 bits, each corresponding
                to, say, 1024. Or whatever is easiest to work with shifts/ands. Then every
                time the "challenge N" stored in RAM increments by 1024, one bit in the
                flash is cleared. At reboot N would be initialized to BASE + (X+1) * 1024
                where X is the count of zerobits and BASE is a variable erased/loaded
                normally.



                Juha, OH5NXO
              • scott@opentrac.org
                Should be ok, as long as you re not concerned with the possibility of a replay attack after a reset. That could be a problem if an attacker finds a bug that
                Message 7 of 8 , Apr 27, 2006
                • 0 Attachment
                  Should be ok, as long as you're not concerned with the possibility of a
                  replay attack after a reset. That could be a problem if an attacker finds a
                  bug that locks up the unit and causes it to do a watchdog reset. I guess
                  you could get around that by incrementing it after every reset, before
                  loading the RAM register.

                  Scott

                  > -----Original Message-----
                  > From: tracker2@yahoogroups.com
                  > [mailto:tracker2@yahoogroups.com] On Behalf Of
                  > juha.nurmela@...
                  > Sent: Thursday, April 27, 2006 12:00 AM
                  > To: tracker2@yahoogroups.com
                  > Subject: RE: [tracker2] Authentication
                  >
                  >
                  >
                  > On Wed, 26 Apr 2006 scott@... wrote:
                  >
                  > > same byte, though you'd only be able to change 1's to 0's.
                  > In any case,
                  > > that'd greatly reduce the number of erase cycles needed,
                  > but it'd still eat
                  > > a whole page. Might be easier to justify if there are
                  > other parameters that
                  >
                  > You could use the 512-byte page (or less) as 4096 bits, each
                  > corresponding
                  > to, say, 1024. Or whatever is easiest to work with
                  > shifts/ands. Then every
                  > time the "challenge N" stored in RAM increments by 1024, one
                  > bit in the
                  > flash is cleared. At reboot N would be initialized to BASE +
                  > (X+1) * 1024
                  > where X is the count of zerobits and BASE is a variable erased/loaded
                  > normally.
                  >
                  >
                  >
                  > Juha, OH5NXO
                  >
                  >
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                • scott@opentrac.org
                  I ve got the authentication list mechanism implemented now. I ll probably upload it tomorrow - it needs a new version of the config program to avoid having
                  Message 8 of 8 , May 30, 2006
                  • 0 Attachment
                    I've got the authentication list mechanism implemented now. I'll probably
                    upload it tomorrow - it needs a new version of the config program to avoid
                    having the list wiped out every time you modify the configuration there.

                    The syntax is as follows:

                    AUTHLIST prints current list
                    AUTHLIST +callsign adds callsign to list
                    AUTHLIST -callsign removes callsign from list
                    AUTHLIST NONE erases list

                    I've been considering implementing two access levels, but at this point I
                    don't think it's worth it. There shouldn't be many authorized users, and
                    generally you're either going to trust them or not. I can see where it
                    might be useful to allow public access to certain things, though. But I
                    don't want to get into maintaining an access list for each command...

                    I've got a pretty good idea of how I'm going to implement the strong
                    authentication format, but I'm still working out the intermediate one. A
                    session logon where you only have to authenticate once and can issue
                    commands over maybe a 5-minute period would be convenient, but it would
                    leave you open to spoofing - someone could wait for you to start a session
                    and then inject a command that appeared to come from your station.

                    Maybe it's good enough for what it needs to do, though. The truly paranoid
                    will still have another option.

                    Scott
                  Your message has been successfully submitted and would be delivered to recipients shortly.