Mobile ID, Singularity, Encryption, Loyalty programs, NFC, Passwords, Bit Rot, ZODB

Post date: Jan 19, 2014 1:42:17 PM

• Thoroughly studied Mobile ID Authentication including APPLICATION GUIDELINE FOR ETSI’S MSS STANDARDS and Certificate & Authentication Policy (in Finnish)
  • I basically like concept of mobile auth & sign. But there are a few questions. Even if the trusted execution environment (TEE) software and it's secrets would be 100% secure, there's another problem, which is the actual device accessing the TEE module. How well the interaction between user and TEE is protected on OS level? What if device is rooted, what if it's operating system is backdoored? Are they still sure that this concept works flawlessly. If there isn't additional information about this protection, I would assume, it's not going to work and it is therefore inherently hackable. That's why having 100% separate hardware for authentication & message signing would be much more secure approach. Possibly continued discussion @ Google+.
• I really like Kan Ban, because. Starting projects and tasks which you won't finish, just consumes resources and therefore prevents other projects and tasks from getting finished. I have been very aware about this. Being highly selective on projects which you even start is simply being smart. - This is my opinion after a long discussion about having and starting a multiple tasks which you won't be able to ever finish.
• Building a safe NFC ticketing system.
• Strong passwords policy?
  • Tapiola bank: "Salasanan pitää olla 6-8 merkin pituinen, se ei saa sisältää erikoismerkkejä eikä Å-, Ä- tai Ö-kirjaimia. Salasanan täytyy koostua kirjaimista ja numeroista, kahta samaa merkkiä ei saa esiintyä salasanassa peräkkäin. Salasana ei saa olla sama kuin käyttäjätunnus. "
  • S-Pankki bank: "Salasanan tulee koostua 4-6 numerosta. Verkkopankki ei hyväksy pelkästään samoista tai peräkkäisistä numeroista koostuvia numerosarjoja, kuten esim. 1111 tai 123456."
  • S-Pankki is saying, that password must be 4-6 digits, but must not contain a series like 1111 or 123456. But main point is that password is limited to maximum of 6 numbers. That's great. Not.
• Studied Bit rot, Soft error, Data corruption, Software brittleness, Disk rot, Harddisk error rates, Advanced format, Triple modular redundancy, Nothing new, but I know from experience that many people totally ignore there problems.
• Reminded my self about Technological Singularity, Strong AI, Accelerating Change, Artificial Consciousness including Consciousness in Digital Computers (Awareness, Learning, Anticipation, Subjective experience)
• Shortly played with Scrapy, web site data scraper for one project which needs to collect data from web sites. Because it's non commercial play project, I don't want to pay for expensive API fees because they offer same data for free on web.
• Is encryption ready for consumer use? Why it wouldn't?
  • "Why is this encryption question so hot topic? Correctly done encryption is totally or nearly seamless, it isn't a problem. You're using LinkedIn over HTTPS hopefully as well as Skype is encrypted, your mobile phone's air interface is encrypted etc. So when encryption is done right, you don't even notice it. Same applies to email encryption. You can configure mail servers to take care of mail encryption, clients hopefully already use only encrypted connections at this point. Or if you want end-to-end encryption, you can use GPG, and just select that contacts which you have public key for, automatically encrypts messages. It wouldn't be a big step, to automatically fetch those public keys, but current (my) client app just doesn't do that yet. All these issues are easily solvable. Technology is totally ready, it's just if people care enough to start using it. Often only reason for not using encryption is, that I don't care, and current solution works just fine. Btw. Outlook and Gmail also encrypt email by default, as well as does my own (and my friends servers) server."
• Loyalty program discussion:
• "Actually several businesses have been planning to implement loyalty system. But usually at that point I turn my consulting mode on, instead of blindly selling them something. And ask what's the gain? Of course I can invoice you a lot for this system. But what do you gain and your customers gain from this system? Usually after a few hours of talking, they decide to decline the need for loyalty system. Of course I would be really happy to provide one, if they can tell what the real benefits are. But often it seems that there aren't too many, or those are actually too hard to exploit or utilize. So even if they would successfully collect the data, so what? If it's not used for anything meaningful it's also pointless to collect it. I think Lidl in Finland got absolutely great loyalty system. They just provide cheap prices and you'll save 15-30% on instantly. You don't need to wait for months to get great 5% cash-back. "
• About temporary data storage, journaling, data persistence etc.
  • "I also checked out the ZODB, yes, it might be good for temporary storage. But as main database it isn't a good option as far as I did read. It doesn't handle possible crashes properly. If you use SQLite3 as temporary storage, it's a good idea to disable journaling. But otherwise disabling journaling leads to corruption after a crash / fail. It's important to remember that tuning persistence parameters can drastically improve or lower performance. That's one of the reasons why people say that Riak is so fast, it doesn't persist data on transaction. Which is in other environments absolutely required. Based on this you can also enable write-back caching and disable journaling on temporary disk volumes. If crash happens, just reformat whole volume and discard all temporary data. In that case journaling and (proper) committing only radically lowers performance."
• Still few more CCC videos, like: The Database Nation aka The State Of Surveillance in India, Electronic Bank Robberies,
• Studied Software Defined Perimeter (SDP) (PDF) documentation from CSA.