Developed On Hackaday: Need Card Art — Who Likes To Draw?

Our offline password keeper project (aka Mooltipass) is quite lucky to have very active (and very competent) contributors. [Harlequin-tech] recently finished our OLED screen low level graphics library which (among others) supports RLE decompression, variable-width fonts and multiple bit depths for fonts & bitmaps. To make things easy, he also published a nice python script to automatically generate c header files from bitmap pictures and another one to export fonts.

[Miguel] finished the AES encryption/decryption schemes (using AES in CTR mode) and wrote an awesome readme which explains how everything works and how someone may check his code using several standardized tests. We highly encourage readers to make sure that we didn’t make any mistake, as it was one of you that suggested we migrate to CTR mode (thanks [mate]!).

On the hardware side, we launched into production the top & bottom PCBs for Olivier’s design. We’re also currently looking for someone that has many Arduino shields to make sure that they can be connected to the Mooltipass. A few days ago we successfully put the Arduino bootloader inside our microcontroller and made the official Arduino Ethernet shield work with it.

Finally, as you may have guessed from the picture above our dear smart card re-sellers can pretty much print anything on them (these are samples). If one of you is motivated to draw something, please contact me at mathieu[at]hackaday.com!

On a (way) more childish note, don’t hesitate to give a skull to the mooltipass on HaD projects so it may reclaim its rightful spot as “most skulled“.

32 thoughts on “Developed On Hackaday: Need Card Art — Who Likes To Draw?

  1. No doubt there’s tons of awesome artistic talent throughout the readership, but my vote is to keep the card design nice and simple… all black with the HaD logo right in the middle. :)

  2. Moin,

    a word of warning: the current AES “CTR” implementation is incomplete (the actual CTR part is missing) and highly susceptible to wrong use. The example given in the readme actually is insecure because of that. Where it says “Here we must increment ivector” there should be actual code, and, since the code is always needed and the security is completely broken if the code is missing, it should be in the aes256CtrEnc/Dec functions. As is, this is even worse than ECB.

    I don’t have time just this instant, but will see whether I can whip something up over the weekend (if nobody beats me to it).


    Henryk Plötz
    Grüße aus Berlin

    1. Maybe you’ve missed to read this part of the README.md:

      ->”We must decide how to generate the initialization vector formed by nounce+counter” so … we already know the ctr part is incomplete. You’re open to participate inside google groups and contribute with the team.

      Thanks !

    2. Maybe you’ve missed to read this part of the README.md:

      ->”We must decide how to generate the initialization vector formed by nonce+counter”

      So … we already know the ctr part is incomplete. You’re open to participate inside google groups and contribute with the team.

      Thanks !

      1. Moin,

        I did not miss this, but those are two distinct issues: Choosing an IV is crucially important, that’s true, and a weak IV will break the system. However, that is not part of the actual AES-CTR implementation (and hence I didn’t remark on that). Updating the counter *after* being given an IV (which only happens once during an encryption sequence, that’s what the ‘I’ stands for) *is* the job of the AES-CTR implementation and must be done by any code that purports to do CTR – preferably without any outside assistance as that will always lead to someone doing it wrong.

        Cryptographic APIs must always be inherently hard to use incorrectly. Exposing the ‘IV’ on subsequent rounds and requiring the caller to update it is a prime example that *will* lead to wrong use. The underlying AES code is a much better example: A context to store local state, one initialization function and then only encrypt and decrypt functions that operate on whole blocks. Nothing unexpected happens, nothing expected does not happen. There’s no way here for someone to, for example, forget to calculate the round keys.

        An AES-CTR API could (well, should, really) follow the same pattern:
        int aes256_ctr_init(struct aes_256_ctr_ctx *ctx, const uint8_t *key, const uint8_t *iv, size_t iv_length);
        int aes256_ctx_transcrypt(struct aes_256_ctr_ctx *ctx, uint8_t *data, size_t data_length);

        (Since encryption and decryption are identical, only one function is necessary. Since CTR is a stream cipher mode of operation, the data can be of arbitrary length.)


        Henryk Plötz
        Grüße aus Berlin

        1. Hi Henryk,

          Thanks a lot for your very pertinent observations.
          Keep in mind that jim17’s native language is not english when interpreting his message ;).
          Following your comment, we’re actually starting to change the code :).
          I’m going to send you a message so jim17 may benefit from your expertise.

          Mathieu

  3. “The concept behind this product is to minimize the number of ways your passwords can be compromised”

    And this device does nothing other than protect against brute force attacks but allowing you to use very complex passwords, it does not minimize the number of ways a password could be comprised. Brute force attacks on websites are difficult to successfully pull off since many will limit the number of failed login attempts, and even if they did not bruteforcing a small character set and password length such as 62^8 is generally infeasible for a number of reasons.

    This produce completely ignores much more common and prevalent attack vectors such as malware or keystroke loggers, which it could address, but that would require a lot more effort than modifying some USB HID simple code someone else wrote. But hey, it has a Arduino in it, so all the fanbois at HaD will support it.

    1. Yep, could you expand on how you would do that then? If it hasn’t been done already then why would a open-source project working almost for free do it? Nothing is secure over the internet and it all can be MITM’d; not to mention easy to crack wireless networks.

      Still a step in the right direction, there should be some sort of guard inbetween the mooltipass and the potentially (most likely) infected computer; maybe only run in ram but I’ve seen malware to boot before that.

      1. How you would do that? To bypass keystroke logging have the device be something other than a HID device and use a firefox (or whatever) plugin to fill in the credentials, to bypass malware have the device sit between the computer and gateway, monitor the web traffic and login for you.

        And why would a open source project working for free do it? The same reason why nearly every other open source project does it. All this is, is a Arduino circlejerk. More effort is being put in to designing logos then actually designing a product which would improve security. Really, Mattieu is reducing all your passwords/phrases in to a single 4 digit PIN, and somehow trying to tell you this makes you more secure.

        1. Hey Matt,

          Seeing your comments I don’t know if you’re actually serious or just trolling.

          And this device does nothing other than protect against brute force attacks but allowing you to use very complex passwords
          >> I fail to see how this is a bad thing…. isn’t it the definition of a good password keeper?

          it does not minimize the number of ways a password could be comprised.
          >> open source hardware, open source software… have a look at the discussions we had when we first discussed this project and you’ll see why this is better than a PC-based password keeper.

          This produce completely ignores much more common and prevalent attack vectors such as malware or keystroke loggers, which it could address, but that would require a lot more effort than modifying some USB HID simple code someone else wrote.
          >> The only way to create a safe system would be to make partnerships with websites directly to share a common secret. If you have another good solution, please expand here!

          But hey, it has a Arduino in it, so all the fanbois at HaD will support it.
          >> Have a look at my website (www.limpkin.fr) and find ONE project that uses an Arduino. How is allowing more users to use the Mooltipass by making it Arduino compatible a bad thing?

          How you would do that? To bypass keystroke logging have the device be something other than a HID device and use a firefox (or whatever) plugin to fill in the credentials, to bypass malware have the device sit between the computer and gateway, monitor the web traffic and login for you.
          >> that’s why we’re saying that we’re just minimizing the number of attack vectors. Have a look above, you’ll see the only way to be immune to this kind of attacks is to share a secret between a website and you.

          Really, Mattieu is reducing all your passwords/phrases in to a single 4 digit PIN, and somehow trying to tell you this makes you more secure.
          >> This sentence is wrong in so many ways that I don’t even know where to begin

          1. So anyone who doesnt take part in this circle jerk is troll? Right… how about you go back to reddit where you can downvote anyone who doesnt agree with you.

            ” I fail to see how this is a bad thing…. isn’t it the definition of a good password keeper?”
            Your device isnt advertised solely as a “password keeper”, as I quoted your readme, it said “The concept behind this product is to minimize the number of ways your passwords can be compromised” which is blatantly false. There are plenty of things it could do it which it doesnt.

            ” have a look at the discussions we had when we first discussed this project and you’ll see why this is better than a PC-based password keeper.”
            I have better things to do than to search countless google group posts, HaD articles and whatever other discussions to make your argument for you. You really ought to ask yourself why it isnt in your readme, and why you’re spending more effort on creating graphics for a smart card than you are on your documentation.

            “The only way to create a safe system would be to make partnerships with websites directly to share a common secret. If you have another good solution, please expand here!”
            No. Create a (insert your favorite browser here) plugin. Have this plugin obtain a list of websites which have creditals stored on your device. Have the plugin get the credentials from the device and enter them in to the website. This bypasses the entire HID layer, and prevents the credentials from being captured by a keystroke logger.

            ” Have a look at my website (www.limpkin.fr) and find ONE project that uses an Arduino.”
            http://www.limpkin.fr/index.php?post/2013/10/09/Easy-phi-project%3A-the-template-module
            you say “The main microcontroller is the ATSAM3X8E from Atmel… You may have guessed that it is the same microcontroller that Arduino uses for its Due, as we want Easy-phi modules to be Arduino compatible….The latter allows programming via the Arduino IDE.” There are countless other references to Arduino on your website as well.

            “How is allowing more users to use the Mooltipass by making it Arduino compatible a bad thing?”
            Well if accessibility is your goal, why not just use a old Blackberry? There are far more of them out there, they can often be had for free used, or at the very least less than a Arduino. And unlike your project, it is actually FIPS 140-2 certified.

            ” that’s why we’re saying that we’re just minimizing the number of attack vectors.”
            The definition of minimize (according to google) is “reduce (something, esp. something unwanted or unpleasant) to the smallest possible amount or degree.” You are not reducing the number of vectors to the smallest possible as i’ve pointed out.

            “Have a look above, you’ll see the only way to be immune to this kind of attacks is to share a secret between a website and you.”
            The shared secret you speak of is called a password.

            ” This sentence is wrong in so many ways that I don’t even know where to begin”
            I’d love to see you try so I can point out how you’re wrong.

          2. “Have this plugin obtain a list of websites which have creditals stored on your device. Have the plugin get the credentials from the device and enter them in to the website.”

            Should have been:

            “Have this plugin obtain a list of websites which have creditals stored on your device. IF IT IS ON A SPECIFIED WEBSITE, have the plugin get the credentials from the device and enter them in to the website.

          3. No. Create a (insert your favorite browser here) plugin. Have this plugin obtain a list of websites which have creditals stored on your device. Have the plugin get the credentials from the device and enter them in to the website. This bypasses the entire HID layer, and prevents the credentials from being captured by a keystroke logger.
            >> How does this protect you from a malware located on your computer?

        2. A firefox plugin? Maybe like a Tor browser bundle? That’s secure right? For all the times you’ve called everyone an idiot here I was expecting to have my mind blown.
          I’ll just make you laugh w/ my ideas, they’re too extreme. They work though, and I want to actually sleep easy at night so I keep trying b/c there’s still unacceptable holes. Any network, can’t trust the other side; can’t do that can’t get work done and make money.

          And I know it’s an Arduino circlejerk, it’s become a running joke here I think. I can do things I never would’ve been able to w/o it though (won’t have time). And it’s a nice platform to burn a custom bootloader when I can and want to and have a custom board where I can practice PCB design and having a real product to market. I’m still going to design my own computer too, so it’s not just fanbois who like Arduino; real engineers do too. Right now have an urge to build a simple adder, then read up on radio and prepare my computer-turned digital radio station. The blinky-LED’s and “wearable electronics” crowd isn’t for me either. I want to see you link to a post where you hack this device too.

          1. “A firefox plugin?”
            To address the issue of keystroke loggers, but if you would have bothered to read the rest of my post you would have noticed “…to bypass malware have the device sit between the computer and gateway, monitor the web traffic and login for you.”

            “I’ll just make you laugh w/ my ideas”
            What ideas? You didnt list any.

            ” I want to see you link to a post where you hack this device too.”
            wut? this device isnt even finished. If you want a link where I have found remotely exploitable critical security vulnerabilities which relate to encryption then here:
            http://www.securityfocus.com/bid/37953

    2. Moin,

      > And this device does nothing other than protect against brute force attacks but allowing you to use very complex passwords.

      Actually, it does one other, very valuable thing: Since the database is not kept on the PC and is not directly accessible, malware on the computer can not directly take off with the database *and* the encryption passphrase (which is the case with any and all non-hardware assisted password keeper software solutions). Compromises would be limited to the passwords you actually used on the compromised machines.

      The HID thing is just a red herring by the way: A) I don’t think it’s going to be the primary use method. It is useful for a quick and dirty approach where you want to use your passwords immediately on a random computer with no software setup. It does however lack proper bidrectional communication. And yes, a Firefox plugin (or equivalent) is a logical integral part for three reasons: I) comfort (have the plugin automatically select the right password database entry), II) additional functionality, such as also entering the accompanying user name, III) additional security functionality: The plugin could also let the device implement some form of TLS pinning so that the password entry is linked to the certificate hash on TLS sites.
      B) If the computer is infected with malware, you have lost. Period. Full stop. Klappe zu, Affe tot. Any discussion of the type “A maximally naive software keyboard logger will pick up HID reports but not custom USB data” is just a sham. Malware on the host, by definition, can do anything, and what is worse, you can’t even determine after the fact what it can do. (One of the reasons why virus scanners are egregious snake oil, but I digress.) When the host is infected, there really is no reason why the malware shouldn’t scan password fields for contents. And actually: This is the more likely attack vector. A friend of mine who specialises in the javascript attack surface was rather adamantine in his dismissal of the Firefox built-in password keeper, because that can sometimes be broken by attacks from the web.

      Obviously, again, a better™ solution is some sort of bidirectional cryptographic authentication between the site and some local trusted device (nota bene: Even then you’re screwed if you have local malware installed: it will just take over the session after you’ve logged in). This area is overwrought with stupid-ass patents, so no widespread solution, besides full-on TLS with X.509 client certs on a smart card, seems likely in the future. In the mean time, things get better (with TLS against active, always against passive, intermediaries on the communication line, and against a certain subclass of locally installed malware) by using one-time passwords (HOTP/TOTP), which is a planned feature for the Mooltipass. These are now available on a growing number of websites, but user adoption is still pretty low. One possible reason is the user-facing overhead. An automated tool like the Mooltipass has the possibility to overcome that burden (and add a thing or two, like TLS pinning). Maybe, at some point in the future https://en.wikipedia.org/wiki/FIDO_Alliance will get somewhere.

      I agree with you insofar, as I’ve also said privately to Matthieu, that “almost good” in a security device really would be bad and an unconscionable shame in an open project that so much work has gone into. But, luckily, most things, that are not the base cryptographic design, can be fixed in iterations, building on both feedback and contributions.


      Henryk Plötz
      Grüße aus Berlin

  4. Arduino circlejerk… Is that like an Arduino powered jerk chicken rotary unit.. Because if it is, it sounds tasty!! mmmmm… BBQ Circlejerk chicken.. *drools*

    On another note im totally up for making some super awesome designs for the Mooltipass.

    ~chicken.. good~

  5. I remember you once released a board(forgot what it was) that had your logo silkscreened on one side but it was modified. It had traces or something coming out of one side.That thing was awesome! You couald use that again!

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.