Viable options for password based, feature lock authentication via unencrypted serial link
(decided to move this from Software Engineering Stack Exchange immediately after posting...)
I'm after some general good practice advice/options on this one. To provide some background first, I'm working on a fairly mature product development with (for the purposes of this discussion) 2 major components;
- a physical device (the saleable product) + it's embedded firmware
- a Windows .NET configuration application/GUI for setting up the device's configurable parameters The project is mature, with several years worth of development. The embedded target is severely resource constrained (Cortex M0+ with no vendor added cryptographic capability), and runs a proprietary bare metal real time task scheduler, but no full RTOS. Application is niche, with a small global user base (hundreds).
We would like to add the ability for some of the configurable features to be locked behind password authentication; i.e. only certain users, such as our own service personnel are able to change these.
Configuration is via serial port between the device and a PC via a proprietary communication protocol that handles things like CRC checking of data frames, splitting of large packets etc, i.e. robust but entirely unencrypted, read: robust comms protocol via RS232. We do not have anywhere near sufficient free application space to run something like WolfSSL, nor is this deemed to be necessary in this instance, justification below.
So, to the question - what viable options are there for authentication in this case? We are not encrypting sensitive user data such as financial data, legally protected personal data etc, and neither are the ramifications of breaking the chosen method of authentication remotely severe (plus, are entirely detectable in logs on both the embedded and PC end). The functionality is fundamentally to prevent end users changing advanced configuration settings which they have neither the need to, or suitable knowledge to do so correctly, resulting in support calls of "I changed some settings, and now my device doesn't function as I think it should".
Current thought for a lightweight process is:
- Store password hash in MCU flash
- Prompt for user password in GUI
- Hash password using a lightweight hash algorithm
- Send hash via serial link, and check against stored hash to accept/reject configuration upload
But, we'd like at least some basic protection against active man in the middle attack, as without this sending the hash is barely any better than sending the password as plain text.
Thoughts on options at this point? Our proprietary serial comms protocol is fairly complex, to the point that the reverse engineering effort required simply to open and maintain a comms session, may even negate the risk of somebody simply recording a byte stream during config upload, and injecting this byte stream at a later date - given the stream will simply be rejected by the device for being outside of an active comms session. Not to mention, anybody with the skillset to do this, is not the sort of person we're trying to protect against at all. We're trying to protect an average user, from themselves, combined with the bare minimum of preventing any man in the middle hardware being able to grab the plain text password.
