I do not know trustzone either, some links might related: http://superuser.com/questions/689570/uefi-vs-arm-trustzone http://stackoverflow.com/questions/17485367/trustzone-versus-hypervisor
"mmcblk0" seems the internal storage, correct? It is very clear that if the value of it get changed on some scenarios, the installed apps won't be decrypted back correctly which is disaster. 1. On system upgrade? 2. If the storage is broken and replaced by another, does the value change? If so, I doubt the application will break. 3. User hacked (maybe needed not considered). Thanks, Halton. From: Ye, Jingfu Sent: Wednesday, July 09, 2014 3:03 PM To: Huo, Halton; Poussa, Sakari; [email protected] Subject: RE: [Crosswalk-dev] Intent to Implement - Tizen Web Application Protection #1, I am not quit clear whether IA has the similar technology like trustzone. Is there any hint for further investigation? [halton] I do not know either, google give me some: http://superuser.com/questions/689570/uefi-vs-arm-trustzone http://stackoverflow.com/questions/17485367/trustzone-versus-hypervisor #2, the NAND_CID_NAME is the path pointing to a device file "/sys/block/mmcblk0/device/cid" on wearable device. The mobile device does not have the file thus probably implements the function SysSecBootGetDeviceUniqueKey() in hardware. E.g it's specific to device. Jingfu From: Huo, Halton Sent: Wednesday, July 09, 2014 2:15 PM To: Ye, Jingfu; Poussa, Sakari; [email protected]<mailto:[email protected]> Subject: RE: [Crosswalk-dev] Intent to Implement - Tizen Web Application Protection See my comments in line. From: Ye, Jingfu Sent: Wednesday, July 09, 2014 12:12 PM To: Poussa, Sakari; Huo, Halton; [email protected]<mailto:[email protected]> Subject: RE: [Crosswalk-dev] Intent to Implement - Tizen Web Application Protection Sorry for delay responding. I attended a training in the last two working days. I've investigated the implementation in Tizen WRT 2.x. The details are as below: 1. If running on ARM, it would call the arm trustzone<http://www.arm.com/products/processors/technologies/trustzone/index.php> API TzCrypt_Encrypt(). The encryption & decryption are done within trustzone and no need to store key outside. [halton] Does IA has trustzone like technology? 2. If not running on ARM, read seed data from NAND_CID_NAME and compute a key based on the seed. This can ensure the generated key is unique to the device. [halton] What is NAND_CID_NAME? Google give nothing on that word. 3. If NAND_CID_NAME is not available, set the seed as a buffer of 0xFF and compute the key based on it. This is similar with #2. I think we can follow Tizen 2.x. For #1, if the trustzone is not available on xwalk at present, we can leave it in the future. For #2, I am not sure whether we can read seed from NAND_CID_NAME or from some other hardware device. If there is no relevant API, we can start from #3 at present. (In the long term I feel the xwalk runtime need a security component running at low level and providing some basic functionalities like encryption, digital signature and so on.) Please let me know your comments or suggestions. ------ implementation in Tizen 2.x (in framework/security/libcryptsvc) ---------- SecEncryptTZCrypt(*src, srcLen, *Dst, *DstLen,....) { #ifdef CRYPTOSVC_TZ // TZ stands for TrustZone ret = TzCrypt_Encrypt(Src, SrcLen, Dst, DstLen); #else SecFrameGeneratePlatformUniqueKey(KEY_SIZE, key); // compute key, see below function .. AES_Crypto(Src, Dst, key, iv, 1, SrcLen); #endif } bool SecFrameGeneratePlatformUniqueKey(IN UINT32 uLen, IN OUT UINT8 *pCek) { bool bResult = true; unsigned int i = 0; unsigned char Key[73] = {0}; unsigned char hashedValue[HASH_LEN] = {0}; int nTempLen = SEC_DUK_SIZE; int nHashLen = 0; int remain = 0; unsigned char *result = NULL; SLOGD("[LOG][%s:L%d] Enter \n", __func__,__LINE__); #ifdef CRYPTOSVC_TARGET SysSecBootGetDeviceUniqueKey(Key); #else memset(Key, 0xFF, nTempLen); #endif /* for debugging */ SLOGD("Device Unique Key Information \n"); memcpy(Key+nTempLen, SEC_FRAME_OSP_KEY, 9); nTempLen += 9; remain = uLen; for( i = 0 ; i < uLen ; i += HASH_LEN ) { result = SHA1(Key, nTempLen, hashedValue); nHashLen = HASH_LEN; if( result == NULL) { SLOGE("SecCryptoHash fail \n"); bResult = false; goto ERR; } nTempLen = nHashLen; if( remain < HASH_LEN ) { memcpy(pCek+i, hashedValue, remain); } else { memcpy(pCek+i, hashedValue, nHashLen); } remain -= HASH_LEN; memset(Key, 0, sizeof(Key)); memcpy(Key, hashedValue, nHashLen); } SLOGD("[LOG][%s:L%d] End \n", __func__,__LINE__); ERR: SLOGD("[LOG][%s:L%d] End with ERROR \n", __func__,__LINE__); return bResult; } void SysSecBootGetDeviceUniqueKey(unsigned char* pUniquekey) { bool result = OemNandInfoUID(pUniquekey, SYS_SECBOOT_DEV_ID_LEN); } bool OemNandInfoUID(unsigned char* pUID, int nBufferSize) { int fd = 0; char szCID[NAND_CID_SIZE+1] = {0,}; memset(pUID, 0x0, nBufferSize); fd = open(NAND_CID_NAME, O_RDONLY); // read from NAND_CID_NAME //generate UID from the NAND_CID_NAME. } ----------------------- Thanks, Jingfu From: Poussa, Sakari Sent: Friday, July 04, 2014 7:31 PM To: Huo, Halton; Ye, Jingfu; [email protected]<mailto:[email protected]> Subject: Re: [Crosswalk-dev] Intent to Implement - Tizen Web Application Protection Agree with Halton. Totally not OK to use hardcoded keys in the src code. Please study how it was done in the Tizen WRT 2.x and we can review that proposal. Sakari From: <Huo>, Halton <[email protected]<mailto:[email protected]>> Date: Friday, July 4, 2014 at 11:57 To: "Ye, Jingfu" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Crosswalk-dev] Intent to Implement - Tizen Web Application Protection Hard coded key string should not be acceptable. You intent is to protect the HTML/JS/CSS files. Hard coded is very easy to hack them out. Thanks, Halton. From: Ye, Jingfu Sent: Friday, July 04, 2014 4:55 PM To: Huo, Halton; [email protected]<mailto:[email protected]> Subject: RE: [Crosswalk-dev] Intent to Implement - Tizen Web Application Protection Hey Halton, Thank you for the good question. Actually I am still thinking about it. Regarding the algorithm, I have some rough idea. I feel we can involve the "crypto" component within our xwalk project. So the basic algorithm can be based on the following class: == class Encrytor { public: bool Init(key, mode, iv); // the mode would be "CTR" bool Encrypt(plaintext,*ciphertext); bool Decrypt(ciphertext, plaintext); }; == Here the key can be generated by the utility function crtypo::SymmetricKey::Import(AES, key_str). And the "key_str" is the key you mentioned. I think we can simply hardcode the key string within the source code. I am not sure if it's safe to do. I see the sample codes from the file "encryptor_unittest.cc". Please let me know your suggestions. Thanks, Jingfu From: Huo, Halton Sent: Friday, July 04, 2014 4:10 PM To: Ye, Jingfu; [email protected]<mailto:[email protected]> Subject: RE: [Crosswalk-dev] Intent to Implement - Tizen Web Application Protection Hi Jingfu, What encrypt/decrypt algorithm will be used? If need a key, how the key is provided? If the key stored locally, how to protected the key? Thanks, Halton. From: Crosswalk-dev [mailto:[email protected]] On Behalf Of Ye, Jingfu Sent: Friday, July 04, 2014 4:00 PM To: [email protected]<mailto:[email protected]> Subject: [Crosswalk-dev] Intent to Implement - Tizen Web Application Protection Summary For Web Applications that explicitly turn on the "encryption" through the <tizen:setting/> element in the configuration file, the WRT MUST provide the following two measures to protect Web Application resources: - The WRT MUST encrypt the HTML, JS and CSS files of the Web Application stored by the device. - When the Web Application is being run, the WRT MUST decrypt the encrypted resources(HTML, JS and CSS) in the manner transparent to the application. Spec Reference to the Tizen 2.x spec(https://source.tizen.org/sites/default/files/page/tizen-2.2-wrt-core-spec.pdf). Affected Components xwalk installer; xwalk applicaiton Related feature in JIRA https://crosswalk-project.org/jira/browse/XWALK-1491 https://crosswalk-project.org/jira/browse/XWALK-1172 Target release Crosswalk 8 Target Platform Crosswalk on Tizen Implementation details 1. At installation stage, if the "encryption" is turned on, encrypt the HTML, JS and CSS files when unzipping resource from the application package. The file path and name keep unchanged. 2. At the application running stage, if an encrypted resource is requested, start an asynchronous URLRequestJob task to load the encrypted resource and decrypted it. The decrypted stream is returned to render process. Thanks, Jingfu
_______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
