I am building a small TOTP based lock, but I want it to be able to generate a new shared key whenever a (say) reset button is pressed, or a certain combination etc. The new shared key would then be used to generate a QR code for the user(s) to input into their phones. For my intended use this might only happen once a year or so, therefore it seems a bit excessive to include a dedicated e-ink or LCD to the box for this once/year application (couple reasons - the physical container is limited in size, and I want to limit the number of pins needed).
What are my other options for outputting data from the Arduino without a display or serial output? I am thinking writing the data to a sd card, or something along those lines. Can anyone think of another cheap (in terms of pins needed) way to output such a code to the outside world?
Hi, can you provide links to the stuff you are talking about please.
What is TOTP based lock?
What is e-ink?
What are the keys, card, dongle ...?
What is you application, what are you trying to accomplish and with what?
I hate to sound ignorant but I have no idea what you are asking.
Is it an option to plug a PC onto the Arduino when you want to change the key? Then you could probably use the Arduino Serial Monitor.
Another possibility might be to have a bluetooth connection and write a little app for the phone so it can provide the display.
None of this is meant to negate the need for answers to other people's questions.
Wow, thanks guys for the quick responses! I am sorry I didn't supply enough information at the outset. Sorry for that, I am still very much a beginner with Arduino and building circuits. Here are some answers to your requests for clarification:
TOTP = Time Based One Time Password, often used in 2-factor authentication protocols (like banks use, or your Google account if you have 2-factor auth turned on). The peripherals for the Arduino to make this work are a keypad (usually a matrix style) and a RTC (Real Time Clock) module that simply keeps time. Your phone can keep time as well (obviously), so in theory (and in practice, hey!) if both have an arbitrary "shared key" i.e. a code of some sort - e.g. "MyArduinoTotpSharedKey" or "hakjdfy98234hjfiuy6dbg" then both can take that code plus a time stamp (usually in 30 second blocks or "periods"), run them through an algorithm (a standard one is called RFC 6238 - outlined here RFC 6238 - TOTP: Time-Based One-Time Password Algorithm), then both can calculate the same (6 digit) numeric "passcode" without divulging the shared key to the user. In this scenario I am using the TOTP code as the only authentication instead of a second one. In other words the project I am building is a lock that will only open when a user looks up the current code on their phone and enters it before the end of the current time period.
E-Ink = E-paper = a screen that displays an output, often used in e-readers. Kind of like the LCD one that comes with most Arduinos, but the advantage in this scenario is that it needs no power to keep an image on screen indefinitely - it is a graphic made up of physical pixels. If I had the pins free to do this I would likely generate and output a QR code to the e-ink display and have it stay there, displayed inside the lock for anyone to scan into their phones (but they'd have to get someone else to open the lock first).
Shared Key = as above this can be anything at all, you just need to define the length in the TOTP code, which I have done at 10 digits. It seems a code of 10 alphanumeric digits should be enough for this purpose - and yes GrumpyMike, it could be shorter than that too, it's easy to adjust the length.
Another way of formulating my question is: "my code is generating a 10-digit random alphanumeric string, storing it and somehow communicating that code to the outside world, without the use of an LCD or serial output. It is the communication-without-LCD-or-serial-output bit that I wanted help with. As Robin2 mentioned it looks like the only options are to include a serial output or bluetooth module. Grumpy_Mike your suggestion might work too (I even thought of outputting morse code or something, since there will already be LED's involved) but it might not be user-friendly and I'm hoping the lock will be able to be used by lay-people without my involvement. ("Instructions: push the reset button, then scan the new code using "Google Authenticator" on your smartphone").
Thanks for all of your help so far, i have a sneaky suspicion there is no "easy" way to do this, so may have to just include the LCD after all...
Should probably also mention that before I deploy this lock for real-world use I was planning to "shrikify" the project into a dedicated microcontroller - e.g. ATtiny or, if I have to include serial output, then a dedicated ATmega328P chip...
If in the end I don't find a feasible solution to communicate outwards, then I will resort to "hard coding" the shared key into the program - i.e. it cannot ever be changed. That is how I have it running at the moment.
ajlowndes:
Another way of formulating my question is: "my code is generating a 10-digit random alphanumeric string, storing it and somehow communicating that code to the outside world, without the use of an LCD or serial output.
You have provided a lot of supplementary material but I am still a bit confused.
My original suggestions were based on my (incorrect, I think) assumption that some user interaction was needed when the code needed to be changed.
I now get the impression that generating a new code is done simply by switching on or restarting the Arduino. Does that mean that an "accidental" reset will create a new code? is that what you want to happen?
Assuming the Arduino has a new code what is to be done with that code?
It sounds like some device (a phone or PC?) needs to connect (in some way) to the Arduino to request and be given the code.
Will that happen immediately after the Arduino is switched on?
Or is it the case that immediately before your device requests a new code the user should either switch on or reset the Arduino to make sure they get the latest code?
I find it hard to reconcile what I have just said with the idea that it only needs to happen once per year.
No you were correct the first time around, I imagined the final circuit would pretty much stay powered on all the time until the batteries run down. I have a small safe at home that has a keypad-input exactly like my one will, and that is run on 4 AA's and lasts a couple years or so on that, without losing the code you set (but of course it doesn't have TOTP...yet). If power is lost to the safe, the code is re-set to the factory default one... I guess the arduino one would have to follow this example because there wouldn't be another way to store the shared key.
To be honest I haven't really finished sussing out exactly how the key-reset process would work - I'm just exploring options that's all, that was the point of this post.
Obviously in order to reset the key some method of communicating the new one to the outside world will be needed, but everything (except maybe binary or morse code using the LEDs) will require an extra number of pins - I'm already restricted by the fact that the matrix keypad needs 7, power needs 1, the RTC will need 3 or 4 (can't remember if one is just ground), the 3 LED's need 1 each...there is a sound crystal in the safe I could also use needing 1. That's 16 pins already, though I could probably drop one of the LED's making 15 pins. Judging from that I may need to either upgrade to a ATmega328P giving me a lot more pins and serial output, or just stick with the 16 pin ATtiny I already have (haven't sussed out if it even has enough resources to run the program - haven't got to the "shrinkify" stage yet as I'm still prototyping). Sticking with the ATtiny looks like it will mean not having a code reset option.
Hmm... I just thought... another approach could be that the user could generate their own "random shared key" and enter it via the keypad and also into their phone (or website or whatever). The shared key is therefore communicated inwards (but restricted to numerals) rather than the program generating it and communicating it outward.
Anyway, thanks for all of your help with my brainstorming guys. Sorry that the way I explained things is confusing - I'm a beginner remember
How many pins do you have left? I'd use a serial addressable led display like the SCD55104A. Its small, about the size of a Atmega 328 PDIP package (28 pin DIP).
It only uses about 5 pins, and they can display 10-digits at once, or you could scroll
longer shared secrets. Expensive brand new but you can find them surplus easily. If you just need one, PM me. They also look super cool and have some low-power shutdown modes.
ajlowndes:
Judging from that I may need to either upgrade to a ATmega328P giving me a lot more pins and serial output, or just stick with the 16 pin ATtiny I already have
If you are only making one of these (or just a small number) it's a mistake to focus on reducing hardware costs at the expense of your own convenience and the long-term usability of the device. When you are making a million and hoping to have a profit after Tesco or Walmart have had their cut, hardware pennies matter.
