posted Jan 19, 2014, 5:42 AM by Sami Lehtinen
updated Mar 2, 2015, 6:41 AM
- 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
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
- 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.