Safe and Sound - Encrypted password book for your pocket

Hello,

I worked for a while and now finished a first functional prototype of: SAFE AND SOUND (SAS) which transforms your Arduboy into a pocket sized encrypted password book and key generator.
In fact this is not a game but a very usefull gadget.

-It will keep all your passwords safe and sound and only you have quick access to it.
-The password is easy to remember but also strong at the same time.
-The device will never be online or connected to any network so it will stay uncurrupted.
-No way for anybody to install a keylogger or break your PC firewall.
-You can also generate keys for other software like for hard drive encryption tools.
-Send crypted notes to a friend and nobody will be able to hack this communication.
-The device it self can store up to 7 notes with 128 characters each.

SAS2

The Programm:
HTTP://WWW.3DARTLAB.DE/SAFE-AND-SOUND.ino

Instructions:
HTTP://WWW.3DARTLAB.DE/INFO.TXT

At the moment its a prototype. It works and so far no bugs detected but the safety have to be tested.
Im sure theres a lot to emprove and my programming code looks chaotic and crazy for
every professional programmer :slight_smile:

I hope some of you like this idea and I hope to get feedback and find some programmer and hacker want to try to test and hack it.

At the moment I still wait for feedback from Arduboy side for some weeks and it is not sure how to progress with it, launching it somewhere like on Kickstarter or maybe even changing the platform.

I wish you much fun testing it and looking forward to any kind of feedback.

Cheers
Markus

2 Likes

What encryption algorithm does this use?

The last time someone published a password encrypter on this forum he wrote his own algorithm,
and then someone proved it was weak against a plain-text attack so he had to abandon the project.

I can see a long list of issues with the code (e.g. if (1 == 1) is always true, and it’s a bad idea to use global variables as a loop counter),
but if the algorithm isn’t actually secure then improving the code is a waste of time.

Hi Pharap,
thank you for your feedback.
The if(1==1) is just a lazy way to /* */ to deactivate some function temporary, i did it during programming and delete after. I forget to delete it in some cases what causes no problems but looks just not fine, I already deleted it right now and uploaded the code again.
Using global variables in a big programm can create some issues right specially if many people work on separate parts I guess. But this programm is in variables and code size mini and only I did the programming so theres no issues with that global variables used for loops, just some part of my chaotic programming style sorry. But yeah, as I said before many small things can be improffed. I guess at the moment its more interesting is the main thing works, secure and usuable.
The plain-text attack shouldt be find any gap to this encrption method.
I not use some common method I guess, its something own written and I guess only some experts and people try to hack it can proof if this agorypthm is safe.

Generelly Im using passwords easy to remember because they are combinations of pressed buttons on the arduboy. Every key can be some comination of 6 pressed buttons in order, thats a quite lot of combinations. Some keys are just one or two button combinations but its impossible to know for the attacker which of the 16 keys are long.

The algorithm alterhing the content of every single character inside the text by the key value and by the value of the text itself, multiply times, and also replacing the position of the characters with each other again by value of key and containing values. Just changing a single element of the key or changing a single element of the text will result in a complete different output of the crypted / uncrypted content.

We can setup a quite easy password, crypting a text, and make it public for solving.

I guess thats what I do next.
Do you like to hack it?

Cheers
Markus

Hi! I finished a first week challenge. With a bit brute force it should be possible to hack it, its using a much weaker password as I suggested as minimum standard:

Info:
Key with 1x6 buttons, 1x5, 1x4 and 1x3 and 4x2. The unused 8 keys are once pressed “B” buttons.
Where the "A"s located inside the key and the real password keys is unknown.
The text is plain text without taking care about encryption, spaces, “.” etc used.
And more as the half of 128 characters used for it. The rest are " " blank characters.

Crypted text:

P5YA!%ÖS2TG2CU3E

,SHßO!DÜRY2\P@/$

O<!%/FÜCOWKD.O0N

$!>TG9S.0:X,@E76

">YMB=3Ö<A9V!35\

Ü?"01!F6GJ-Y3,ÄÜ

YH2SXEA7Ö2NC4$(6

IZ#0WC/ CEÜ9EEI,

and yes at the last line it is a " " empty character at position number 8.

Good luck, most lately if somebody is able to hack this I upload a message crypted with normal safety.

I like the ideia of having my password on a HW wallet. Just like the bitcoin HW wallet.
Nice idea!

It doesn’t deactivate it though, 1 == 1 evaluates to true, which means it’s effectively if(true) (which is then pretty much ignored by the compiler, so it’s as if the if(1==1) wasn’t even there in the first place).

There are issues.

Local variables can be stored in registers, which means they sometimes don’t consume any RAM, and even when they do consume RAM they’re stored on the stack, not the global variable area, so the memory they use is reclaimed after the function returns and can be reused by other variables.

Globals on the other hand must exist in RAM, and the compiler absolutely has to write the variable’s value back to RAM every time the global is modified, which requires extra CPU instructions compared to just using a register.

In other words, local variables are much cheaper and more efficient than global variables.

Example

Here’s an example from an Atmel technical document
A program using a global variable:

#include <avr/io.h>

uint8_t global_1;

int main(void)
{
	global_1 = 0xAA;
	PORTB = global_1;
}

Uses 104 bytes of progmem and 1 byte of RAM.

The same program modified to use a local variable instead:

#include <avr/io.h>

int main(void)
{
	uint8_t local_1;
	local_1 = 0xAA;
	PORTB = local_1;
}

Uses 84 bytes of progmem and 0 bytes of RAM.

It works and it’s usable, but determining whether it’s secure or not isn’t an easy task.
(One of the golden rules of encryption is “don’t write your own encryption algorithm unless you’re an expert”.)

All I know for definite is that there’s only 672 possible keys,
so brute forcing shouldn’t take much time.

I’ve had a read of the code, but I think it would take quite a bit of time to crack and I have too much else to do.

One thing I will point out is that all the variants of moveValid are all actually just the remainder operation:

int remainder(int element, int modulus)
{
	int value = (element % modulus);
	return (value >= 0) ? value : (value + modulus);
}

(If it weren’t for the use of signed numbers (int8_t instead of uint8_t) then this would be equivalent to %.)

There’s a potentially huge problem with using globals in a security application, the attacker could have much easier access to changing or observing them if they had malicious intent. It really depends on how they are used in your program but it is a potential attack surface you are exposing.

1 Like

In fairness, if an attacker was close enough to the Arduboy to be able to hijack the addresss bus then you’d be screwed anyway.

Or were you thinking of something else?

There is no address bus. Since the RAM, flash and EEPROM are internal to the chip along with the CPU, none of the data buses are exposed to the outside world.

Hi! thank you for all that feedback.
I adviced at the instructions never connect the device again to any PC etc. only use direct USB power chargers. Theres no need to connect it again to a computer after installing SAS at the device. So on that side im sure if hackers try long enough they can hack the device via usb connection, for example replace the original programm with one also saves your passwort in some way and after reconnecting again to that infected PC copy and delivery that passwort including the memory with all crypted notes to the attacker. But as said easy to solve, lets hold the device independend. Oh by the way you can use ONLY power usb cables where all other connections are cutted, so you can even load the device at your PC without opening any communication way to attack it.

And Pharap youve written there are only 672 possible keys?
May I ask how you get that number?
A single key which can be 6 buttons pressed in orders, by using 6 buttons have:
6x5x5x5x5x5 combinations ( you have to hold one key so after the first 6 buttons you will have 5 for the next step to choose from) and this are 18750 possible combinations, for a solo key. And the order of
the button and the keys itself are also important, replacing one in order changing all.
But we going to use as I suggest at least 2x6 buttons + 2x5 buttons + 4x2 buttons ( and 8x1 buttons for the rest of the 16 keys)
5button keys have 3750 combinations each, 2 buttons have 6x5=30 combinations, and a solo key have 6 because there are 6 buttons available.
So we have 18750x18750x3750x3750x30x30x30x30x6 whiche are impossible
to bruteforce as I think, thats: 2,4E+22 combinations (if the 8xsolo button keys are all the same button without altering, like A,A,A,A,A,A,A,A, so you realy just remembere 8 keys and one button for the rest of the keys keeping it easy)

And a attacker cannot know where are the long keys stored inside the password, so the variations you have to try out is quite quite amazingly bigger! Thats one main strength we not even take care at this calculation. You can calculate how big we get in combinations, if the first 18750 can be stored in 16 positions as one key, its 16 places, the second 18750 can be stored in 15 still free places, and so on.
Gives us a result like that:
18750x16x
18750x15x
3750x14x
3750x13x
30x12x
30x11x
30x10x
30x9x
6…
1,2E+31 combinations

And with “hacking and finding some weekness” I was meaning if we can find some weekness of the algorithm which allows to solve the crypted text after crypting. Without hacking the device itself which we cannot get access too because its ofline.

And yes I know that “rule” that only a expert should write their own algorithm, but it brings the problem with it that you have to believe somebody else in things you maybe not understand fully, or more worse a lot or a group of people, and if you analysing a huge open source encryption programm you maybe dont see just a mini gap in security, maybe made to not be seen, or they change it that way in some update, its just nearly impossible to garant safety at a complex programm in a compley enviroment etc. thats why I want to give it a try to create a independend device with an easy programm everybody can understand, so I just hope it also genereates unbreakable crypted results.

That bring us back to the point that I have no Idea to use any method like the “plain-text attack” or other to uncrypt that thing without the password.

Any ideas?

The for loops now use local variables and that saves some ressources. Programm still works fine after modification. I uploaded it right now.

2 Likes

You’d be surprised how hackers can gain access to executing unsigned code from just user accessible interfaces by exploiting flaws in the way a system handles them. Of course it’d likely be a lot of work for little payoff, but for something which is meant specifically for a security application it’s worth at least considering.

Fair point. I keep forgetting all the memory is built into the chip.


So you have to manually type the password into the computer?

I must have been asleep, I accidentally did 7 * (16 * 6) instead of 7 ** (16 * 6).
(** being exponentiation/the pow function).

It’s actually 1.3471372384942765478320065677219e+81,
or 13471372384942765478320065677219e+40 if you’d rather.

The 16 and 6 are the dimensions of the 2D key array (the password for the secret text),
but each of those bytes has only 7 possible values, one for each key (UDLRAB) and 0 for ‘no key’.

Though with parallelisation that could still be brute-forced reasonably quickly.
The bigger problem is just being able to recognise when it’s been cracked.

Technically it’s permutations because the order of the digits is important.

You don’t necessarily have to depend on a library,
but depending on a tried-and-tested algorithm at least tends to be a good idea.

For a plain text attack you’d need a copy of the plaintext and a copy of the encrypted plaintext.

I think in this case it would make things slightly easier because you would have a way to verify that you’d found the key when trying to brute force the encryption.

I think the most likely way to speed up cracking the key would be to find a way to measure whether or not certain swaps are more likely than others.

I can think of a lot more improvements, e.g.

  • using a proper swap function instead of doing a manual swap each time
  • using switch statements
  • using enum classes instead of integers for the state machine
  • getting rid of the expressions that compare bools with ints

but the code isn’t licenced (i.e. it’s ‘source available’ rather than ‘open source’),
so technically I can’t actually publish the code if I modify it.


Between Heartbleed, Spectre and goto fail; very little surprises me.
Even microphones and speakers can be exploited,
and it’s possible to increase the duration that RAM will hold data for after the power is cut by freezing it.
There’s no shortage of inventive exploits out there.

It’s probably slightly easier on desktop than on an embedded system though.
Dynamic linking adds a lot of possibilities for abusing API calls for example.

On the Arduboy the easiest way to abuse physical access would be to just hook the Arduboy up to another computer via USB and use the bootloader commands to dump the EEPROM (and possibly the progmem) and then crack the saved data at leisure.

1 Like

I’ve read through theFlow’s blog on how he managed to hack the PS Vita open and the ROP chaining of manipulated gadgets within the built in psp emulator all within a secure, encrypted system to eventually elevate privileges to the point that unsigned code can be executed for native vita apps blew my mind. No level of intentional security stands a chance against someone motivated enough to break it, and security through obscurity stands an even weaker chance.

1 Like

Yes if the attacker have to believe you maybe use the full password and not just enter for example 2 times a long 6element key, etc. in, you come to a quite awesome number of possible key combinations like 1.3e+81. The fact that the key just have elements with 7 possible states dosnt make that number smaller, a key is like a character, normal passwords have lengths of 8-12 characters or so, and using for examples letters a-z, A-Z, 0-9 and 10 special symbols or so, so lets say 80 differenct characters.
SAS using 16 keys with 18750 states (6x5x5x5x5x5), so its quite an improvement of password safety but can be rememberd easily the same time.
And about brute forcing it, the problem as you said is you dont know if you guess the right password before you try and fully uncrypted the content with it.
We are talking round about 100000 operations needed to try out one key.
If u use CUDA and your graphic card and running 2500 cuda cores with I dont know lets say 2gigahertz (i know its quite more complex to see how many operations can be done by per single gpu tact but in that case a round about will be enough) we can try out 2500x2000000000/100000 possible keywords of SAS every second. Thats 50,000,000 keys per second, 100,000,000 with a dual gpu like im using for BLENDER renderings at home.
Thats just 5,00E+07. If you try to crack only a week key with 2E+30 or so you will need… just 1,29E+15 years to brute force it :wink: or lets say you can hack a key in one year with a combination ammount of arround 1,56E+15 and we are never going to use that week keys.

And yes the problem using the port as only access was the reason to define never use it again after installing SAS. Best not only using only power chargers via usb instead of computers or only power connecting usb cables, best you destroy the usb port somehow lol just let the power connections functional. So even if somebody take your wallet and your device, he cannot connect it easily.
And one more thing, just by reading the rom out dosnt help the attacker because he just get the crypted code, code you can also share open because it should be save if your password is. Just this password you have to keep save. It should be deleted and automaticly deletes after arround 10 minutes if you forget to turn the device off in menue.

By the way its maybe a quite awesome idea to give that gadget loaded on laser engraved and SEALED arduboys ( to open the device and the USB data ability too).By the way I the laser engraving I already did hope you like it.

Oh and one more thing, it should be even same or close same impossible to get the key even if you know both the crypted AND uncrypted text! Thought about it?
The way the content and the key works together in a complex way I guess you have to try out the same way as you want to find the key.

About the improvements you suggest, your fully right, And about
the licence, I have had and still have no actually plan how to go forward with that, if just open source, and how to publish. I was writing with Kevin here from the Arduboy guys, he was quite friendly and interested, it seems to be a bit complicated how to run such compains like he did with arduventure in themes about licences, when and if to open source it and so on. I believe we can do without any problems, but the code was not finished at that state and now after some weeks I finished it and write him but dosnt get any feedback for some time now. Maybe hes in holiday, I still wait for response.
And I want to see what people thinks about it and specialy if they can help me figure out about how save the algorithm works. So I decided to start it here at the board.

The topic open source licences seems also to be quite big, I only did one project that way as I remember, juming snake a small Arduboy game.

If you like Pharap I have absolutly nothing against it if you like to help to polish the programming style of that code. At the moment I only do changes relevant to this post, but I can stop and change nothing as long as you work on it if you like to improve some style things as the improvements you was suggesting before. And I will upload it again. I just hope we not have to change the algorithm of encryption itself because I already test running the application, if the algorithm gets modified I have to enter the content im testing right now again again :wink:

Cheers and a big thank you to all for all that Feedback!
Markus