|
Home
| pfodApps/pfodDevices
| WebStringTemplates
| Java/J2EE
| Unix
| Torches
| Superannuation
|
| About
Us
|
|
|
SipHash Secure Challenge and Response
|
by Matthew Ford 15th July 2018 (original 12th
January 2013) – Added No EEPROM design
© Forward
Computing and Control Pty. Ltd. NSW Australia, All rights reserved.
This page outlines a design and software for a Challenge Handshake Authentication Protocol (CHAP) to securely access to a micro-device based on Atmel AVR / Arduino hardware. It is based on SipHash. An alternative design based in HMAC-SHA256 is described here. Keys in the range of 64 to 128 bits are supported depending of the level of security required. An Arduino library implementing this design for pfodDevices is available here.
The pfod Specification provides a simple way to control a micro-device (pfodDevice). The pfodApp is an implementation of the specification for Android mobiles and it completely removes the need to do any Android programming. The present implementation of pfodApp connects to the pfodDevice via Bluetooth. However the means of connection or its security is not specified by the pfod Specification. So the establishment of the connection and any authentication are 'out-of-band' with respect to the pfod spec. A connection via wifi/internet is also permissible and is available in the lastest versions of pfodApp.
Once you allow connections to your pfodDevice via the internet, security becomes a major consideration. With short range bluetooth, a non-discoverable and pin protected pfodDevice (using some other pin instead of 0000 or 1234) is reasonably secure. However when the connection is via the internet, there is a significant risk from port scanners finding the open pfodDevice port and so gaining control of the device.
To protect against this threat, I am proposing a 'secure' Challenge Handshake Authentication Protocol (CHAP) to access the pfodDevice and a per-message data-integrity and authentication check.
The verification that the pfodApp has authority to
control the pfodDevice is based on a shared secret password.
a)
After the completion of the link establishment phase (opening a
TCP/IP connection), the pfodDevice (authenticator) sends a
"challenge" message to the pfodApp (peer).
b) The
pfodApp (peer) responds with a value calculated using a one-way hash
function on the challenge using the secret password.
c) The
pfodDevice (authenticator) checks the response against its own
calculation of the expected hash value. If the values match, the
pfodDevice (authenticator) acknowledges the authentication and starts
accepting pfodApp messages, otherwise (if the response is incorrect)
the pfodDevice terminates the connection.
d) Then for each message
send between the pfodApp and the pfodDevice, a secure hash of the
challenge+msgCount+message, using the “secret key”, is
appended to ensure data-integrity and authentication.
For the one-way hash function, MD5 was used previously. MD5 has now been superseded by SHA256 (and others hashes). In this design I am using SipHash. The designers of SipHash maintain it is not subject to attacks that are less intensive the a brute force attack to discover the secret key.
To protect against concerted attacks using powerful computers, longer keys should be used. Key of lengths of 128bits (32 hex digits) are unlikely to be broken (see the brute force wiki entry).
The response is 64 bits, but because the challenge is never repeated, an attacker only gets one chance at guessing the correct response. That chance is vanishing small at 1 in 1e19. The challenge is 64bits. What is important about the challenge is that it never be repeated. (See below for how the challenge is generated).
For each pfod message sent between the pfodApp and pfodDevice, a 32bit hash (8 hex digits) is added to verify the message comes from the pfodApp / pfodDevice and that the message has not been changed.
The 'secret' key is supplied with each pfodDevice and should be random (see below for an easy way to generate 'random' keys). The minimum of 64 bits or 16 Hex digits was chosen to providing practical security against opportunistic attack, but by using QR code images to transfer the key from the pfodDevice to the pfodApp there is no reason not to use 128bit secret keys.
There are two main threat that this proposal is
designed to guard against:-
1) to prevent a remote hacker finding
the open pfodDevice ip and port, connecting to it to control its
functions,
2) to protect against a hacker with access to the
network from taking over control of the pfodDevice from you once the
CHAP handshake is complete. (Man-In-The-Middle attack)
To see just how easy it is to set up a Man-In-The-Middle attack, just do a web search on “wifi man in the middle hardware”
This design does not protect against taking control
of, or denying access to, the pfodDevice in the following cases
i)
Where the attacker has physical access to the pfodDevice which would
normally have the 'secret' password attached to it. (forcing a power
cycle is protected against.)
ii) Where the attacker has physical
access to the Android mobile where the 'secret' password has been
entered. If you loose you mobile you must change the pfodDevice
password.
iii) Denial of Service attacks, where the attacker
prevents you from accessing the pfodDevice by the attacker
continually trying to connect to the pfodDevice and failing to gain
access.
pfodDevice listens on an ip:port for a connection.
On receiving a connection the pfodDevice remains silent
If the pfodDevice does not receive a request for a challenge within short time, it closes the connection and listens for another one.
The pfodApp sends a connection prompt. For example {_}. Any other msg causes the pfodDevice to close the connection.
The pfodDevice responds with a 64 bit number encoded as 16 Hex chars, the challenge, plus a one byte (2 hex chars) hash identifier. e.g. {_FFFFFFFE00000CBC02} (see below for how this unique non-repeating challenge is calculated). The pfodDevice also calculates the valid response using SipHash and the “secret key” A SecretKeyGenerator application is available here, which will generate a 'random' 128 bit secret key and save it in a QRcode image.
The pfodApp calculates the valid response via SipHash, using the 'secret' key and this challenge and sends the 64bits (8 bytes) result, Hex encoded, back to the pfodDevice, e.g. {_|BA7816BF8F01CFEA}. 'secret' keys with less then 16 bytes are padded with trailing zeros. Full 16 byte (128bit) keys are recommended of the best security.
The pfodDevice compares the response with its own calculation. If it is not equal, the pfodDevice drops (force closes) the connection. If it is equal, the pfodDevice keeps the connection open and replies with {_} and then awaits the normal pfod first message, in plain text (usually {.} requesting the pfodDevice's main menu).
At the end of the connection, when a challenge was sent, the pfodDevice calculates the next challenge and valid response before accepting another connection.
For each plain text control message and response, the pfodApp and pfodDevice append 8 hex digits which are the first four bytes of the SipHash of the challenge+msgCounter+message and the secret key. The receiver of the message looks for these extra chars after the message } and checks that they are the correct hash. If not the the connection is closed.
Point ii) above, where the pfodDevice is silent, reduces the chance of a random port scanner from being given any information about what has just been connected to. However the following analysis assumes the attacker knows that a pfodDevice is on a particular ip:port and has been monitoring the previous traffic on that port.
At point v) the pfodDevice sends a challenge of a 64bit (8 byte) number (one of 2e19 possible numbers). The security depends on the pfodDevice never sending the same number twice so that even if the attacker has listened to ALL the previous traffic, they will not know what the correct response is to this new/different number without knowing the secret key.
At point vi) the pfodApp calculates the valid response. Using an 64 bit return, there is less then 1 chance in 1e19 that a attacker will guess the correct result by chance.
At point ix) each message has a secure 32 bit hash added to it. Because a message counter is included, repeated commands have different hashes. Because the non-repeating challenge is include, the same message sequence in different connections has different hashes. A hacker has on average a one in 2e9 chance of spoofing the correct hash by chance. Before a hacker can attempt to spoof a message, he must first wait for you to complete a successful CHAP logon and then take control of the session. Any incorrect hash closes the connection. See below for how you can increase this level of security.
This design provides protection against Man in the Middle attacks. In these attacks, the attacker inserts themselves between you and the pfodDevice and intercepts all your messages and relays them to the pfodDevice, or replaces them his own messages. However because each message has its own hash which depends on the shared “secret key” that the attacker does not know, if the attacker modifies the message being sent to the pfodDevice or inserts his one of his own, he will not know what correct hash to add to the message and the connection will be closed by the receiver.
Also because the pfodDevice also adds a secure hash to its responses, the attacker cannot modify the menus presented to the pfodApp and so cannot induce the user to send a particular command.
The security of this method depends on never sending the same challenge twice, so the attacker cannot know the valid response just by listening to all the previous traffic.
There are 2 (two) versions of this calculation:- EEPROM and No EEPROM
The EEPROM
version is for those microprocessors that have EEPROM available. It
is is the most secure and uses EEPROM to keep track of the power
cycles
The No EEPROM
version is for use with microprocessors that do not provide EEPROM.
It is is somewhat less secure, see the
Uniqueness of the Challenge discussion
below, and uses a random number on
power up instead of the previously stored power cycle from EEPROM.
The challenge 8 byte (64 bits) and
is made up of 3 parts. Each part is sent in Big
Endian format.
a) Power Cycles – a 16 bit counter of the
number of power cycles. In the EEPROM
version it starts from 0xFFFF, decremented and stored back in the
EEPROM
on power up. In the No EEPROM
version the Power Cycles is a random number calculated on power
up.
b) Connection Counter - 16 bits from a RAM counter starting at
0 on each power up and incrementing each time a challenge is sent.
When it reaches 65535 and wraps around to zero the Power Cycle number
if decremented (and stored in EEPROM, if available).
c) Time since
last connection and status - 32 bits, 31bits for time since last
connection in mS, 1bit for status of last connection. A random error
of up to 255mS is included in this number.
Finally one byte (2 hex
digits) are added to identify the type of hash to uses. 01 indicates
HMAC-SHA256, 02 indicates SipHash, 03
indicates HMAC-SipHash. Currently
pfodApp only supports type 02 – SipHash
As mentioned above the protection against replaying a previous session, to open a lock again later for example, depends on no sending the same challenge twice. If EEPROM is available this is guaranteed by starting at 0xFFFF when the microprocessor is programmed and then decreasing, and storing, this value on each power up and also each time the Connection Counter wraps around. These two numbers together are unique per connection. Once the EEPROM Power Cycles count down to zero (after 65535 cycles) the code refuses further connections.
The endurance of the EEPROM is guaranteed to 100,000, after this many power cycles the EEPROM may not work correctly. 16 bits gives 65535 numbers which is less then the EEPROM endurance of 100,000 write/erase cycles.
To protect against an attacker denying valid user access by using up all the allowable power cycles by interrupting the uC mains power, a 15sec power up delay will be introduced. This means an attacker would have to cycle the power every 15secs for 11 days (i.e. 65500 power cycles) in order to consume the available power cycle counts. They would then deny valid user access to the pfodDevice, as the pfodDevice will refuse connections. A small battery back up would extend this to an impractically long time.
If there is No EEPROM, then the uniqueness of the challenge can not be guaranteed, but it can be made random which makes is very difficult for an attacker to force the exact same challenge to be sent when they are trying to replay a previous message sequence. In the case of No EEPROM, the Power Cycles is generated from a random number generator in power up.
In both cases, EEPROM and No EEPROM there is a random components in the time since last connection which makes it more difficult to get a repeated challenge.
The random number generator is seeded when the first connection arrives, from the uS since power up. Only the lower 16bits of the 32bit random output is used as the initial Power Cycle number, etc, so as to not expose the current state of the random number generator on the communication's link
The 16 bits from the uC RAM connection counter will count from 0 to 65535. With a minimum of 50mS per connection during which a challenge is requested, sent and an invalid response returned, it will take longer then about 1hr for this number to repeat if connections are continuously made by an attacker and invalid responses sent. When this number does return to 0, the Power Cycle number will be decremented, and stored in EEPROM if available, so that the challenge will stay unique. Using this method of attack it would take about 7 years to use up all the EEPROM power cycle numbers after which the pfodDevice would refuse valid users as well. In the No EEPROM case, the Power Cycles will wrap around back to 65535 and continue.
The 32 bits are divided into 1 bit for the status (the leading bit) and 31 bits from the uC mS counter/timer for the time since the last connection attempt OR since power up if this is the first attempt. It can count up to ~25 days. With the vagaries of wireless connections (the tcp connection takes between 22mS (local) and 225mS(transcontinental) or longer to set up) this number will be mostly unpredictable. However it does tell the pfod Client how long since the last connection attempt was made (if it was made in the last 25 days). The timer wraps around to 0 when it reaches maximum count (2e9 mS).
A random error of up to 255mS is included in this number by xor-ing with the lower 8bits from a call to rand()
The status bit is set, if the last connection failed any of the hash checks, either the challenge or message hashes. If the connection times out waiting for the for connection challenge response to complete, or waiting for the next message, the status flag is NOT set. Only a failed hash check sets the status flag. If this flag is set then it is most likely some tried to break into the pfodDevice. Taking the flag as the sign of the time since the last connection, i.e. flag bit + 31 time bits == 4 bytes, then if the time since the last connection is a negative number, some one tried to break into the pfodDevice.
When using EEPROM, the Power Cycles and the Connection Counter together ensure the challenge is always unique and never repeating. The security of the challenge/response depends on never sending the same challenge twice and on the 'cryptographic strength' of the SipHash
When there is No EEPROM, it is possible that a challenge will be repeated for a later connection. If the device is not power cycled, this cannot happen for at least 7 years (assuming 50mS between connection attempts). If the device is power cycled, then it is possible that a repeated Power Cycle and Connection Count may happen sooner. However, in either case, the Time since the Last Connection including to 255mS random component, makes the chance of sending repeated challenge very very small.
So in summary, the No EEPROM version provides sufficient security for almost all applications. The EEPROM version provides complete security against sending a repeated challenge at a later time.
Assuming the challenge is never repeated, the security of the control depends on the attacker not being able to break the SipHash and recover the 'secret key'.
The message hashes are calculated initializing SipHash with the “secret key” and then adding the challenge to the hash and then adding the message count in bigEndian format, starting from zero and finally adding the message. finish() is than called on SipHash to get the 8 byte hash. Only the first 4 bytes of the resulting hash are send (as 8 hex digits) immediately following the closing } of the message. Note: no white space is allowed between the closing } and the hash bytes. Only the characters from (and including) the opening { to the closing } of the message are including when calculating the hash. White space is allowed inside the message (i.e. between the { and } )
The unsigned long message counter allows for 4e9 messages per connection without any possibility of repeating. At 20mS per message that is 3 years of messages in a single continuous connection.
Each message to the pfodDevice is protected by a secure hash of 4 bytes. This means an attacker has a 1e9 chance of guessing the correct hash for this command.
If you want to make it even less likely that an attacker can guess the correct hash for that “special” command then bury the special command in a sub-menu and code the pfodDevice so that the user has to first request the sub-menu before the command becomes active. This means an attacker has to now send two correct commands with the correct hashes one after another. This decreases the odds to 1 in 10e18 that an attacker can guess these two message hashes correctly. If this is not enough add another level of menu etc..
The implementation of this design consists of two parts, the pfodApp support in the Android mobile and the pfodDevice support code on an Atmel AVR / Arduino device.
The AVR / Arduino programming is straight forward, except for the SipHash hash. Fortunately the base operations for SipHash are simple and can be readily implemented in assembler. A SipHash library for Arduino is available here. A pfodDevice library implementing this design is also available.
SipHash was chosen because it is designed for short messages. Its block size is only 8 bytes and intermediate state storage is only 32 bytes. It is also fast, about 2.1mS for an 8 byte message on an 8Mhz Atmel Attiny device and each additional 8 bytes on the messages only adds about 0.7mS. Finally its simple code structure means it will be possible to break the hash process up into smaller parts so that the main Arduino loop() remains responsive and does not 'goto sleep' for a long time while the hash is being calculated. This will be the subject of future development.
For the pfodApp, again the implementation is straight forward, sample source code is available from a link on SipHash project page. Note: The sample Java code linked to on that page has errors in its implementation, so I re-implemented it for pfodApp. The Java code library for SipHash is available here.
The secret key should not be anything an attacker can guess. That is it should be completely random. See Anatomy of a hack for how easy it is to “brute force” short text passwords. A SecretKeyGenerator application is available here, which will generate a 'random' 128 bit secret key and save it in a QRcode image.
In this application, the password is itself generated by taking the first 16 bytes of the result of the HMAC-SHA256 hash of some text entered by the user and using the output of Java getNano() time as the key. The text can be anything. Because getNano() is used as the key each time a password is produced you will get a different one, even using the same text. The input text can be discarded once the key has been generated. These 16 bytes would then be programmed into the pfodDevice's EEPROM and also attached to the pfodDevice as 32 Hex digits. Note: HMAC-SHA256 is being used instead of SipHash because SipHash only produces an 8 byte (64bit) hash result while HMAC-SHA256 produces a 256 bit (32 byte) hash result.
This approach produces an essentially random password. Anatomy of a hack indicates you that even with a 'random' password, 8 bytes (64bits) the minimum you should use and for reliable protection you need to use 16 bytes (128 bits) to be protect against brute force attacks. Remember, once an attacher sniffs one of your connections, they can spend as much time as they like trying to recover the password. Using QR code image generated by the SecretKeyGenerator, to transfer the password, as described below, there is no reason not to use 128 bit (32 hex digit) passwords.
If the password is only 64bits (8 bytes - 16 hex digits), then it is not too difficult for the user to enter these hex digits manually into the pfodApp. However if a longer, more secure, password is used, say 128bits (32 hex digits) then it becomes difficult for the user to enter it correctly.
For longer passwords the preferred method is to attach the password as an QR coded image to the pfodDevice which the mobile can scan and copy and paste to the connections password field. The SecretKeyGenerator application generates a QR code image of the generated key. There are numerous apps available to scan QR codes such as QR Droid Private .
This page details the design and software of a Challenge Response security for an internet connected micro-processor based, pfodDevice, which will provide protection against unauthorised access and control.
The minimum 8 bytes (64 bits) was chosen to providing practical security against opportunistic attack, while not being too difficult to enter correctly into the pfodApp. By using QR code passwords there is no reason not to use longer keys, up to 128 bits or 32 Hex digits which provide much more protection against brute force attacks.
As described above the chances of an attacker gaining access by sending a valid response to the challenge are vanishing small (<1e19) and “man in the middle” attacks are guarded against by adding a secure hash to each message sent which allows the receiver to check the message has not been changed and that the message comes from the same device that took part in the CHAP authentication.
The biggest risk is a denial of service attack.
There are two main denial of service attacks. In the first one the attacker continually connects, denying access for a period of time before the pfodDevice closes that connection. This is the easiest form of internet denial of service attack. The second type of attack is to consume all the available EEPROM stored power cycle counts. Using up the EEPROM power cycles via an internet attack would take more than 7 years of continuous attacks, each one requesting a challenge from the pfodDevice. In either case the attacker does not gain access to the control the pfodDevice, but only succeeds in denying valid uses access.
In order to gain access to and to control to the pfodDevice, an attacker would need to discover the secret key, either by a monitoring the traffic and trying all the possible keys (i.e. brute force attack) or by gaining physical access to either the mobile phone or the pfodDevice itself. The brute force attack is not possible for longer keys (128 bits).
This design has been implemented and the Arduino library as well as a pfodDevice library has been published and a supporting java library is also available.
AndroidTM is a trademark of Google Inc, For use of the Arduino name see http://arduino.cc/en/Main/FAQ
The General Purpose Android/Arduino Control App.
pfodDevice™ and pfodApp™ are trade marks of Forward Computing and Control Pty. Ltd.
Contact Forward Computing and Control by
©Copyright 1996-2020 Forward Computing and Control Pty. Ltd.
ACN 003 669 994