|
The article devoted to design challenge and clearly states that it was almost a year before design research started, while other researches were conducted, regarding the security model principally. Later there would be separate articles for aspects of security approaches implied within the design of U-HODL, when whitepapers are polished, finished and ready for publishing. Anyway, I would gladly answer any direct questions about the issues you might be interested in, I just don't have a whole article at the moment for your consideration. In short, the statement is as follows: the product would be able to comply with payment processing protocols, like every banking card for example. Additionally, as stated in the article and in the author's comment above - the product designed with the user in mind, what is no less important for customers security according to our vision of the problem. Security is more about a process, and just finally as a result. And hardware wallet is one of the most important instruments that should help customer to build and maintain his own security protocols and behaviour patterns. If the instrument is "cutting your own hands" than it is much less likely that user would apply it most securely and regularly. The simplest example with PIN-code which needed to be entered repeatedly at every simple step or recurring operation, it is most likely that user wouldn't use device at all, or just use a shorter PIN, than doing his replay attack without measure every day. Thus we provide the convenience for user to authorize himself biometrically much faster within a reasonable timeframe, value cap and proximity limitations (very similar to major smartphone industry biometrical practice).
Doing our "user experience" homework, we see our contribution to customers security and assets safety much bigger than just provide yet another "the most secure wallet". It is the most secure both from the technical and usability point of view. |