Saturday, February 25, 2017

The smart card as a design built-in for smart phones

My model is simple.

When an app in the smart phone wants to transact with sandbox security, it calls the security exec function at the hardware level.  The thread immediately enters the hardware protected code, with timeout.  Henceforth, the thread has only one exist point and hardware at the address level forces the thread to stay.  Within the hardware layer, the thread cannot write nor execute unsecured addresses. The protected code will utilize the NFC port, and will exchange data with the OS for secret reasons. Access to the NFC port is via exec function only, and the exe will insure the message sent meets a 'cleanliness' bounds.  This mainly means it is sent to a verified and verifiable destination.

Outside of hardware protect mode the system acts like a standard smart phone.

The hardware protected code is simply unreadable from unsecure addresses, that is the ultimate security.  Like one of those California hotels or a black hole; only one way in or out, but leave the baggage. The secure code comes with the human unobservable private key set, burned in with security by master bot at the fab.

The model for traders is simply that the smart card function duplicates paper in every form except that it uses dynamic exchanges; but these are just as protected as the static watermarks on paper cash. The real fear is the mandate for government exchanges, that is optional.  You fear getting ripped off in the pits? Buy Redneck compatible systems, and read my reviews.

Another name for this model?
Hardware protected spreadsheet with built in double entry cell accounting that can be verified by generating a verification token.

No comments: