[Cocos2D/3D] (2) My First Cocos2D/3D Project

My First Cocos2D/3D Project

Simulator: IPhone 4-inch Retina iOS7
Programming in Objective-C
3D Effects in development based on OpenGL ES
R,G,W represent 3 kinds of 3D effects
FPS: 45~60

And, yes, it's the first prototype of my idea of iOS app.

[x86] (8) How to Customize Signature for Secure Boot using OpenSSL

It's the day we talk about how to customize your signature for notorious secure boot using open source software completely no painless. It's also 100% confirmed by OpenSSL, the software we could trust ain't like those hijacked by specified OS vendor.

Great, shall we begin?

----------------------------------------------------------------------------------------------------------------

(1) Download and Install OpenSSL wherever you like.

(2) Crate your own Certificate Authority on your console:

   (a) Set Directory of openssl.cfg (openssl.cnf), 

    C:\Program Files\CollabNet\Subversion Server\httpd\bin>

    set OPENSSL_CONF=C:\

    copy openssl.cnf openssl.cfg

   (b) Generate 2048 RSA Private Key

    C:\Program Files\CollabNet\Subversion Server\httpd\bin>

    openssl genrsa -out mephisto_cert\ca_privkey.key 2048

   (c) Generate Public PK Key by Private PK Key

    C:\Program Files\CollabNet\Subversion Server\httpd\bin>

    openssl rsa -in mephisto_cert\ca_privkey.key -pubout > mephisto_cert\ca_public.key

   (d) Generate the self-signed digital certification of CA --> ca.crt

    openssl req -new -x509 -days 8000 -key mephisto_cert\ca_privkey.key -out mephisto_cert\ca.crt -sha256 -config ..\conf\openssl.cnf

(3) Generate KEK by Private Key of PK

   (a) Build directory storing KEK CSR, CRT, Private Key.

        md mephisto_svn_server_cert

   (b) Generate Private Key + Public Key for KEK

        openssl genrsa -out mephisto_svn_server_cert\svn_server_privkey.key 2048
   
    openssl rsa -in mephisto_svn_server_cert\svn_server_privkey.key -pubout > mephisto_svn_server_cert\svn_server_public.key

   (c) Produce CSR application document for PK

    openssl req -new -out mephisto_svn_server_cert\svn_server.csr -key mephisto_svn_server_cert\svn_server_privkey.key -config ..\conf\openssl.cnf

   (d) Build directory for CA(KEK)
 
      C:\Program Files\CollabNet\Subversion Server\httpd\bin\DemoCA\newcerts\
      C:\Program Files\CollabNet\Subversion Server\httpd\bin\DemoCA\index.txt
      C:\Program Files\CollabNet\Subversion Server\httpd\bin\DemoCA\temp.txt
      C:\Program Files\CollabNet\Subversion Server\httpd\bin\DemoCA\temp.txt (filled with "01")
      C:\Program Files\CollabNet\Subversion Server\httpd\bin\DemoCA\serial (Rename temp.txt ro serial)

   (e) Produce Digital Certification (KEK) for PK

    openssl ca -in mephisto_svn_server_cert\svn_server.csr -out mephisto_svn_server_cert\svn_server.crt -cert mephisto_cert\ca.crt -keyfile mephisto_cert\ca_privkey.key -config ..\conf\openssl.cnf -days 8000 -md sha256

(4) Generate db by Private Key of KEK

   (a)  Build directory storing db CSR, CRT, Private Key

   md mephisto_db_cert

   (b) Generate Private Key + Public Key of db

   openssl genrsa -out mephisto_db_server_cert\db_privkey.key 2048
   
   openssl rsa -in mephisto_db_cert\db_privkey.key -pubout > mephisto_db_cert\db_public.key

   (c) Produce CSR application document for KEK

    openssl req -new -out mephisto_db_cert\db.csr -key mephisto_db_cert\db_privkey.key -config ..\conf\openssl.cnf

   (d) Build directory storing CA(db)

   C:\Program Files\CollabNet\Subversion Server\httpd\bin\DemoCA\newcerts\
   C:\Program Files\CollabNet\Subversion Server\httpd\bin\DemoCA\index.txt
   C:\Program Files\CollabNet\Subversion Server\httpd\bin\DemoCA\temp.txt
   C:\Program Files\CollabNet\Subversion Server\httpd\bin\DemoCA\temp.txt (filled with "01")
   C:\Program Files\CollabNet\Subversion Server\httpd\bin\DemoCA\serial (Rename temp.txt ro serial)

   (e) Produce Digital Certification (db) for KEK

   openssl ca -in mephisto_db_cert\db.csr -out mephisto_db_cert\db.crt -cert mephisto_svn_server_cert\svn_server.crt -keyfile mephisto_svn_server_cert\svn_server_privkey.key -config ..\conf\openssl.cnf -days 8000 -md sha256

----------------------------------------------------------------------------------------------------------------

There you go, totally original material shared by myself to help anyone would like to escape the control from OS vendor. If anyone's interested, some of you might find my signature (Mephisto.Lai@X.com) embedded in your official desktop or notebook products...

Anyway, leave me questions, suggestions or comments, thanks!

[x86] (7) Comparison Table of TPM 1.2 and 2.0

As the title, simple and easy, ha ha.

[x86] (6) Secure WMI based on SSL Handshaking Between Application and Embedded Controller

Easy and simple topic just explains all. If one would like to make sure certain WMI (usually OEM customized ones, related to EC maybe and 95% of them are trouble makers of system performance!) to be secured without being used by other applications, the following method is considerable.

The idea is simple, application must handshake with EC through SSL to prove it's identity to gain permission to use certain WMI, otherwise the EC will block the request or even shut the system down shown as below.

Great! I believe you got the idea, if you're not, you may do a little study of SSL as well since it's open standard drafted by legendary Netscape. Following is the detailed flow of handshaking, note that only after the handshaking is done, the security of transmission between application and EC is ensured. The blue square "AES Secured" indicates it.

Once the handshake is done, other flow is just determined by OEM/ EC policy which is pretty trivial, crazy PM and annoying supervisors just love it.

Here's detailed flow how the secure transmission between application and EC, they're extremely trivial if you do take a look on SSL standard...not for lazy bones!

This method is not perfect but simply convincing since it's built on the giant's shoulder...

Any questions, suggestions or comments, please let me know, thanks a lot!

[Cocos2D/3D] (1) Preliminary

New label for my new work! Actually I have been working on Cocos2D/ 3D engine survey for a while, so it's time to setup a new label of posts that I would update my latest status on it. As the open sourced game develop engine, their community shows great support to all indie programmers, totally love that. My current status as follows:

(1) Be able to read Object-C codes.
(2) Be able to read the Cocos2D/ 3D hierarchy, which is important since it provide great interface between 2D and 3D objects.

[x86] (5) Talking about the Working Model of OEM and ODM on RSA Keys Manufacture

If you're not familiar with "Security Boot", "Boot Guard" or "BIOS Guard" stuffs, you might find this subject quite boring. In case that, I think the better way is to explain it as usual sarcasm style.

Previous features I mentioned are designed or claimed for better security integration on platform, it's like a series of locks that you might only pass with right identity. For example, assume as following scene:

Lock: blocks the boot flow unless the right key is accepted.

Right Keys: Can only manufactured by OS vendor and OEM/ ODM (OEM has the right to decide to use only OEM key or both of OEM and ODM keys)

Since right keys can only manufactured by OS vendor, OEM or ODM, here's the funny question: What if the right is leaked, who should be responsible for it?

Well, four kinds of situation:

(1) OS vendor's key leaked: No doubt that OS vendor should be responsible for it since none can access the key but their self, right?

(2) Only OEM Key used and it's leaked: Of course it's OEM's fault, however, if this method is used, OEM should maintain a safe server allowing ODM to upload the signature file to be signed by OEM's internal private key and download from the server. Guess what? Some OEM takes the effort quickly but some just take other methods...

(3) Only ODM key used and it's leaked: Of course it's ODM's fault, however, every one would blame it on OEM. If any bad things happen, ha ha, some poor engineer would be kicked out. Don't worry about the supervisor, they always find the way out.

(4) OEM and ODM keys used and one leaked: Why we need this method? Why not only OEM key used? Well, it's because some OEM's too lazy to build the safe server responsible for ODM's signature, but still wanna ensure which ODM leaks their key and make sure ODM wouldn't produce other non-official keys. Oh man, it's really complicated, right? More to that, what if OEM or ODM would like to change or testify their own keys in the same BIOS code-base? There we need the compile switch provided by IBV to determine if the OEM/ ODM keys changed or not in current compile time. It's complicated, however, once built, it's easy to use to OEM or ODM, and lazy OEM doesn't have to own the safe server. How lazy and brilliant. By the way, I'm the guy worldwide first figured out this working model to satisfy the lazy OEM supervisor...

Finally, based on the experience I shared previously.  I realize there are two ways to work in OEM:

(1) To Follow and get SLAPPED by supervisor.

-> Advantage: Keep your job well and stable.
-> Disadvantage: Get slapped all the time.

(2) To Create and get FIRED by supervisor.

-> Advantage: Be creative to flexible working models to satisfy various needs.
-> Disadvantage: Be creative is bitching and jealous supervisor finds excuse to fire you someday.



Any way, it's been cool to share some experience with you, if you find any questions, suggestions or comments, please give me some feed-backs, thanks a lot! 

[x86] (4) Security Features Diagram

End of the Friday already? Great, let's give a sneaky shot on old x86 based security features. I'll explain those stuffs later and let you guys have great weekend first.

Leave me any questions, suggestions and comments as you need, thanks!