Suggestions and Queries on L1 compliance

1,056 views
Skip to first unread message

Jyjesh Thayyil

unread,
Jul 17, 2017, 1:59:37 PM7/17/17
to Aadhaar Registered Devices Discussion Group
Dear All,

Pl use this thread to provide your suggestions and queries on Level 1 compliance.

Regards,
Team UIDAI.

soma rajanarsaiah

unread,
Jul 18, 2017, 3:31:36 AM7/18/17
to Aadhaar Registered Devices Discussion Group
Dear Jyesh,

Please can you share the presentation of the work shop.

with regards,
Rajan Soma

kirubakaran

unread,
Jul 18, 2017, 3:40:06 AM7/18/17
to aadha...@googlegroups.com

Hi There,

 

Also, can you please share the updated specification as mentioned in the workshop?

 

Thank you

 

Regards,

Kirubakaran Selvaraj
Manager – Product Development

Tech Rizes Transdomain Pvt. Ltd.

 

Techrizes Logo Final-small

 


+91 9986483320
kirubakara...@techrizes.net

Tel: +91 80 4261 1430
Fax: +91 80 4261 1445
www.tech-rizes.com

702 7th Floor, World Trade Centre,
Brigade Gateway 26/1, Dr Rajkumar Rd,
Rajajinagar Ext (Malleshwaram West),
Bangalore, 560 055, India

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.
To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.
To view this discussion on the web visit https://groups.google.com/d/msgid/aadhaar_rd/06280fa0-a39e-4000-9a0c-304f236ddb5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

image001.jpg
image002.png

Chung Tran

unread,
Jul 18, 2017, 3:48:34 AM7/18/17
to aadha...@googlegroups.com

Dear UIDAI Team,

Due to the short notice, we can not participate the workshop. We are very appreciated if you can share the presentation (slides) on the July 17th workshop for L1 compliance and any new specification.

Thank you very much.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.
To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Jitendra Bairagi

unread,
Jul 20, 2017, 8:13:51 AM7/20/17
to aadha...@googlegroups.com
Dear Jyjesh,

Please share the presentation of workshop(L1 compliance 17th July).

On Tue, Jul 18, 2017 at 1:18 PM, Chung Tran <tnc...@iritech.com> wrote:

Dear UIDAI Team,

Due to the short notice, we can not participate the workshop. We are very appreciated if you can share the presentation (slides) on the July 17th workshop for L1 compliance and any new specification.

Thank you very much.


On 7/18/2017 12:59 AM, Jyjesh Thayyil wrote:
Dear All,

Pl use this thread to provide your suggestions and queries on Level 1 compliance.

Regards,
Team UIDAI.
--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Piyush Kanani

unread,
Jul 26, 2017, 5:26:02 AM7/26/17
to Aadhaar Registered Devices Discussion Group
Hello Jyjesh,

Kindly send the 1st workshop presentation for Level 1 compliance. Can you also share technical requirement details for the same.

Regards,
Piyush


On Monday, 17 July 2017 23:29:37 UTC+5:30, Jyjesh Thayyil wrote:

Ketan Upadhyay

unread,
Jul 31, 2017, 4:18:17 AM7/31/17
to Aadhaar Registered Devices Discussion Group
Dear UIDAI team

Pl provide L1 device specification with test cases and details on certification with certification agency name.

As most Banks are now asking for L1 device, we need this info to commit on the same. Considering market pressure the above clarification is very urgent and required on urgent base.

Or alternatively pl provide the time-line for certification to clear the air.

Best Regards
Ketan Upadhyay


On Monday, 17 July 2017 23:29:37 UTC+5:30, Jyjesh Thayyil wrote:

ketan

unread,
Aug 3, 2017, 3:01:41 AM8/3/17
to Aadhaar Registered Devices Discussion Group
Dear UIDAI team

For L1 devices pl provide confirmation on following features
  1. Does FIR support is required / not required / Optional (will it be mentioned in Certificate). (As this becomes very large data, the memory requirement and encryption time is needs to be considered)
  2. All 10 finger FMR is required / not required / Optional (will it be mentioned in Certificate). (As this becomes very large data, the memory requirement and encryption time is needs to be considered)
  3. Protobuf support is required / not required / Optional (will it be mentioned in Certificate).
  4. Over the Air (OTA) Firmware update is required / not required / Optional (will it be mentioned in Certificate). As this requires dual provisioning of program area.

 Regards

Ketan Upadhyay

natekar srinivas

unread,
Aug 21, 2017, 2:56:55 AM8/21/17
to Aadhaar Registered Devices Discussion Group
Dear All,

Please find attached Presentation of L1- workshop which was conducted 17th July. 

Regards,
UIDAI- Team, 
L1 Presentation-17 july.pptx

Marco Mancini

unread,
Sep 21, 2017, 3:58:35 AM9/21/17
to Aadhaar Registered Devices Discussion Group
Hello,
 in the presentation there the requirement that TEE must be booted from ROM. Boot should fail in case of tampering ". In a strict interpretation we need a custom boot ROM, which would replace the default bootloader. In a more relaxed interpretation we can try to argue that since the Flash is completely locked and not tamperable from outside, booting from Flash is equivalent to a boot from ROM.

Would the following solution fulfill the Secure Boot requirement: The microcontroller has its firmware stored in an internal Flash. The MCU is locked down so, that there is no way for any external agent to inspect or modify the contents of the internal Flash (the data are never seen on any pin, the JTAG iface is disabled, the Flash cannot be erased etc.). The firmware in Flash is divided into two parts: a bootloader and a main firmware. The bootloader is loaded at manufacturing and then never modified. On boot, the control goes to the bootloader which at first verifies the hash of the main firmware before jumping to it. Also the update of the main firmware is under the control of the bootloader -- the bootloader verifies the digital signature of the new firmware before writing it into the Flash.

regards,
 Marco Mancini

ketan

unread,
Oct 5, 2017, 12:18:39 PM10/5/17
to Aadhaar Registered Devices Discussion Group

Dear UIDAI team


Pl suggest on below L1 architecture, This is having secure boot and Hardware keystore

The TEE here is ARM 9 processor with Hardware random no generation, CMOS scanner interface, volatile key storage with secure RAM module. This uses FIPS certified encryption algorithm. The Processor supports secure boot

The Private key is stored on external FLASH (25Qxxxx) in encrypted value and encryption key is device specific, unique for every IC. This simulates hardware key-store.

 The channel between Censor module and Main board is protected with encryption and board replacement is not possible.



Regards

Hiren Bhandari

unread,
Oct 6, 2017, 11:44:28 AM10/6/17
to aadha...@googlegroups.com

Dear Team,

 

Architecture suggested by Mr. Ketan is not valid as per L1 guidelines.

 

1.       Keystore Memory should be the part of Controller/Processor and should be secured Write Only memory.

2.       If its outside the controller/processor, then anybody can remove the memory/Change the memory and access the keystore.

3.       Keystore memory should be write only memory.

4.       It’s necessary that Host should not access the memory directly and its accessed only by the TEE execution.

5.       Even if the data in external flash is encrypted then also it can be read through multiple read and decrypt attack.

6.       External Flash cannot be protected since its outside TEE environment.

 

If keystore is on external flash then there will be no difference between L0 and L1 device as one of the major objective behind the L1 device is to protect keystore.

If keystore memory is external then it can’t be L1 device.

 

I suggest other L1 device vendors to put in their views.

 

Regards

Hiren

 

 

From: aadha...@googlegroups.com [mailto:aadha...@googlegroups.com] On Behalf Of ketan
Sent: Thursday, October 05, 2017 21:49
To: Aadhaar Registered Devices Discussion Group
Subject: [aadhaar_rd] Re: Suggestions and Queries on L1 compliance

 

--

You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Netaji Rao

unread,
Oct 6, 2017, 1:01:56 PM10/6/17
to aadha...@googlegroups.com

Hardware keystore should not be based on flash, it is supposed to be on hardware secure module (HSM).

Thanks,
Netaji Rao D

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Pratik | Biomatiques

unread,
Oct 7, 2017, 1:45:51 AM10/7/17
to aadha...@googlegroups.com

Dear Team,

 

 

Can we use flash to store firmware or part of firmware in signed and encrypted manner and use on-board processor memory for Keystore? Does this meet L1 requirement?

 

Thanks,

With much gratitude and respect,

For Biomatiques Identification Solutions (P) Ltd.

logo guidelines-12 resized 320

Pratik Patel | VP – Global System Integration

‘Rishi House’, Nr. Kargil Chowk, Piplod, Surat – 395 007, (Guj.), INDIA

Mobile: +91 990 980 4321

Phone: +91 261 2225767

Email: pra...@biomatiques.com 

Image removed by sender.

Dear UIDAI team

Image removed by sender.

 

Pl suggest on below L1 architecture, This is having secure boot and Hardware keystore

The TEE here is ARM 9 processor with Hardware random no generation, CMOS scanner interface, volatile key storage with secure RAM module. This uses FIPS certified encryption algorithm. The Processor supports secure boot

The Private key is stored on external FLASH (25Qxxxx) in encrypted value and encryption key is device specific, unique for every IC. This simulates hardware key-store.

 The channel between Censor module and Main board is protected with encryption and board replacement is not possible.

 

 

Regards

 


On Monday, July 17, 2017 at 11:29:37 PM UTC+5:30, Jyjesh Thayyil wrote:

Dear All,

 

Pl use this thread to provide your suggestions and queries on Level 1 compliance.

 

Regards,

Team UIDAI.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

 

--

You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

image003.png
image004.jpg

Hiren Bhandari

unread,
Oct 7, 2017, 2:39:01 AM10/7/17
to aadha...@googlegroups.com

Dear Pratik,

 

1.       I think You may use Encrypted Nor Flash to store Firmware.

2.       MCU/Processor internal secured write only memory should have private key to decrypt firmware on the fly.

3.       MCU/Processor On the fly decryption method should support AES 128 or AES256 or any other standard decryption method.

4.       This process will make sure that only MCU can decrypt the firmware.

5.       Key is always protected by TEE inside MCU.

 

Hiren

image001.png
image002.jpg

Netaji Rao

unread,
Oct 7, 2017, 3:30:44 AM10/7/17
to aadha...@googlegroups.com
Dear Pratik,

Firmware storage is not an issue as it is supposed to be signed and verified as part of secureboot process.

On-board processor (unless it is secure processor) may not be used for keystore. privatekey is not protected.


------------------------
Device Private Key must be stored in secure Hardware Keystore
         - May be a Secure Processor or a Secure Access Model
         - Must contain TRNG and ability to Sign the biometric
         - Signature must happen in the Hardware Keystore




Thanks,
Netaji Rao D

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Hiren Bhandari

unread,
Oct 7, 2017, 3:44:53 AM10/7/17
to aadha...@googlegroups.com

Dear All,

 

1.       Keystore cannot be used on external Flash or any other memory. Memory chip can be replaced and can be compromised.

2.       Keystore should be on secured processor/Controller with secure access model.

3.       As I mentioned earlier, external flash or keystore can be accessed by Flash Programmer/Reader.

4.       Key retrieved from Flash Programmer/reader can be decrypted by multiple decryption attacks.

5.       I believe External key storage cannot be a secured model.

 

Regards

Hiren

 

 

From: aadha...@googlegroups.com [mailto:aadha...@googlegroups.com] On Behalf Of Netaji Rao
Sent: Saturday, October 07, 2017 13:01
To: aadha...@googlegroups.com
Subject: RE: [aadhaar_rd] Re: Suggestions and Queries on L1 compliance

 

Dear Pratik,

 

Firmware storage is not an issue as it is supposed to be signed and verified as part of secureboot process.

 

On-board processor (unless it is secure processor) may not be used for keystore. privatekey is not protected.

 

 

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

Device Private Key must be stored in secure Hardware Keystore

         - May be a Secure Processor or a Secure Access Model

         - Must contain TRNG and ability to Sign the biometric

         - Signature must happen in the Hardware Keystore

 

 

 

Thanks,
Netaji Rao D

On 07-Oct-2017 12:09 PM, "Hiren Bhandari" <hi...@mantratec.com> wrote:

Dear Pratik,

 

1.       I think You may use Encrypted Nor Flash to store Firmware.

2.       MCU/Processor internal secured write only memory should have private key to decrypt firmware on the fly.

3.       MCU/Processor On the fly decryption method should support AES 128 or AES256 or any other standard decryption method.

4.       This process will make sure that only MCU can decrypt the firmware.

5.       Key is always protected by TEE inside MCU.

 

Hiren

 

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

 

--

You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

image001.png
image002.jpg

ketan

unread,
Oct 7, 2017, 6:57:09 AM10/7/17
to Aadhaar Registered Devices Discussion Group

I had requested UIDAI to define hardware key-store and required certification (if any) during last meeting at UIDAI tech center and also by subsequent mails.


But there is no fix definition and hence I had suggested the most cost effective architecture in group for review and inputs.

  • For Registered device to remain secure, only important thing is Private key used to sign. All other process is well documented and available in public domain.
  • The option suggested by Netaji is best one and I had also suggested same to UIDAI through mail, but at the same time if the certified key-store Module IC (HSM) is used, what is the use of Secure Boot, as the private key itself is secure and even international test certification for these group of ICs are available.
  • The secure boot is actually required, when you have storage of private key on same module with secure area (as suggested by Hiren ).
  • Even if the processor is having ROM for key-store and encryption management, secure boot is not required as this part of execution code cannot be tampered/altered.
  • The guidelines from UIDAI for TEE is secure boot and Hardware key-store. The specs for key-store is about working of encryption (True RND generator, key handling and signing, As per PPT page 4), this all mentioned requirements in PPT is available on TEE processor, it does not mention about the storage of key and key storage for non-powered state is on external flash.
  • The secure boot is diff aspect as given below
    • may require, if processor is handling key and encryption as security module, as in case of few controllers.
    • But if we use HSM IC for key storage and encryption, what is use of Secure boot ?
    • if we opt for ROM (as the market qty can support this) where the program cannot be altered, does secure boot required?

 

As we all are getting inquiry from market for L1 devices, we need to be ready with option and in absence of clarity of Secure boot working and Hardware key-store we are on three diff options L1(-), L1 and L1(+), depending on security of key store.

  • L1(-) is what I had put on this architecture, least secure but most cost effective.
  • L1 is  in line of what Hiren has mentioned
  • L1(+) is in line of Netaji’s suggestion, only if Secure Key-store IC is certified with international key-store with TPM and FIPS 140-2 Single chip module (HSM). certified chip HSM for key storage is undisputable and is in use throughout the world coherently.

 

In case of L1(-) and L1, secure boot is required, for L1(-) to protect key access and for L1 (single chip solution) due to access to security module is only for signed execution code.

 

Do we require secure boot for single chip module HSM? As this is certified and widely used across all platforms throughout the world without any security problem since long ( we all are using HSM dongle to sign).

 

Above all is technical details but when we consider market requirements, there is only L1 and most cost effective solution (in absence of clear mention of no storage of Key on unsecure memory) is L1(-).

L1(+) provides tamper protection (as it is mandatory for HSM used everywhere), but this is optional in specs.

 

We are open with all three options, let’s get final verdict from UIDAI team.

 

I will also request all others to provide tech inputs with positive and negative details.

 

Best Regards

Ketan Upadhyay

+91 9327208489 


On Monday, July 17, 2017 at 11:29:37 PM UTC+5:30, Jyjesh Thayyil wrote:

Netaji Rao

unread,
Oct 7, 2017, 7:34:01 AM10/7/17
to aadha...@googlegroups.com
Secureboot is to ensure that the firmware/software being loaded to memory is not tampered. Otherwise, any fraudulent firmware may be loaded that may pretend like genuine firmware that captures (and steals) biometric data and get it signed by YOUR key. 

Securing keys has no effect in this usecase if boot sequence is not secured.

Thanks,
Netaji Rao D

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Netaji Rao

unread,
Oct 7, 2017, 7:37:59 AM10/7/17
to aadha...@googlegroups.com
Secure boot is for the entire solution, not for the keystore/HSM alone.

Thanks,
Netaji Rao D

ketan

unread,
Oct 7, 2017, 10:07:34 AM10/7/17
to Aadhaar Registered Devices Discussion Group
Dear Netaji

I had mentioned two cases where Secure Boot does not have any security requirements
Case 1:- ROM or One Time Programmable Memory, In this case application code can not be altered.
Case 2:- Where the key store is HSM with key storage and encryption, where as the key can not be accessed any time (exported) and can only be used by passing proper authentication. (same like key-store and HSM dongle).

In above case how come other firmware access the key and sign bio-metrics.  Most of processors available today has protection against reading code from programmed processor.

Your suggestion to use HSM like module is most dependable and hence I mentioned same as L1(+), but in this design secure boot is irrelevant and just adds cost.

If you can visualize how the private key can be compromised in above two case, you are requested to provide specific details so we can strengthen the design.

I am not against Secure Boot, but I like to draw attention to the fact that Secure Boot and Hardware key-store are not only solution. The main attention should be about protection of private key and the TEE should have certification of reputed Lab or standards to ensure the key is secure and protected in all case against tampering.

There are case in Semiconductor industry where the security of ICs are found to be compromised due to some hardware design flow at later stage. Who will be responsible if this happens in any case after few years. That is why either it should be only security of private key and to be established by design and undertakings OR established certification of components ( Processor module, security module or HSM IC) used for key security. This is safeguard for manufacturer and certification agency as STQC and UIDAI does not have any testing facility to analyse chip designs and perform attack test on same.


Best Regards
Ketan Upadhyay


On Monday, July 17, 2017 at 11:29:37 PM UTC+5:30, Jyjesh Thayyil wrote:

Netaji Rao

unread,
Oct 7, 2017, 10:42:10 AM10/7/17
to aadha...@googlegroups.com
Dear Ketan,

1. Storing code/executable in ROM is not practical, it will not allow security/feature updates to our code.

2. Yes, HSM doesnt require secure boot, but would we execute biometric module code also from HSM ? If it possible, then Yes, but it is most unlikely.

3. Secureboot is for the entire device, especially to protect integrity of the TEE and it's code. HSM Can protect itself.

4. Cost effectiveness shouldn't be a criteria for L1 device. Cost will comedown with volumes.
Had we chosen cost effectiveness for fingerprint public devices in 2011, we would have ended up with swipe sensors. Optical sensors used to be expensive, now you know the price.

5. TEE and Hardware keystore are two different things. TEE will not protect keys, it will only ensure execution of trusted components in memory. 
Hardware keystore is responsible for key protection and biometric signature.

6. A device cannot qualify for L1, unless there is a secure processor or secure access module with TRNG and sign capabilities. Anything less than Secureboot+TEE+HardwareKeystore-with-sign is only a L0+ device.




Thanks,
Netaji Rao D


--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.
To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

ketan

unread,
Oct 8, 2017, 5:11:49 AM10/8/17
to Aadhaar Registered Devices Discussion Group

Dear All

 

What I mean by HSM module :-  Single chip security module having Processor, secure memory for key storage, secure memory for processing, True Random no generator, Able to generate various bit length RSA key pair, Able to encrypt , create checksum or sign. This module supports multiple encryption and signing and checksum algorithms and multiple key length. This module normally has execution program in temper proof ROM and handshake is done using crypto. Algorithms are FIPS 140-2 certified and many chip are also certified for TPM. These are widely used everywhere for HSM dongle and other secure commercial application. The program in ROM is secure boot as in cannot be altered or tampered at the same time it is also proof against future updates as it supports multiple algorithms currently being used. We are not depending on chip manufacturer words for this on security as these modules are third party certified by reputed labs.

 

This is to clarify about HSM module and security offered in HSM module is being used for secure commercial use with much higher impact and to-date this is safe. Secondly these are standards and verifiable.

 

Now continuing in the main line of discussion

  1. The device, I had mentioned as L1(-), is fulfilling all criteria of UIDAI and STQC documents published till date. The private key in external flash in encrypted data is nowhere mentioned as not allowed and also encrypted data always does not mean it can be compromised.
  2. The device, I had mentioned as L1, can be achieved by using diff single chip solution, but in this case also many security module on chip are not certified by international lab certification and what we have is word from chip manufacturer about security of this module. There are case in past where declared secure chips are compromised over the time (MIFARE). Few of these chips also does not support true OTA updates. If someone pushes wrong OTA updates or there is corruption during loading of updates, these chips stops working due to secure boot validation failure. If the processor does not support validated OTA update and checks only at runtime, by pushing faulty update all devices can be made useless.
  3. The device, L1(+), can be with HSM and second processor for biometric and other processing. The second processor also can be secure boot if required. But at the same time the task performed by second processor is well documented and does not have any security risk as it does not do signing and encryption ad that is why I was asking what additional security we shall achieve by Secure boot. Even if by wrong firmware someone gets biometrics, it cannot sign it and use in AADHAAR, this also makes device unusable.

 

The response to points of Netaji

  1. (Q. Storing code/executable in ROM is not practical, it will not allow security/feature updates to our code.)  HSM is always in ROM to provide tamper protection, at the same time as it supports multiple key length and algorithm, it does not require updates. The main CPU firmware can be updated and the change in key size or algorithm is possible. In many single chip solution many security module also does the same thing.
  2. (Q. Yes, HSM doesnt require secure boot, but would we execute biometric module code also from HSM ? If it possible, then Yes, but it is most unlikely) Biometric module does not require to be secure as it is any way available in open and anybody can use image extractor. The criteria in L0 and L1 is signing. Even if bio module is secure but the private key is compromised, what is the use. The importance is to keep key secure and sign only valid data.
  3. (Q. Secureboot is for the entire device, especially to protect integrity of the TEE and it's code. HSM Can protect itself.) TEE and key-store in this case is not separate as the Execution logic is public, the only security is signing of BS, and this is done in HSM or in security module for single chip solution. Injection of biometric image is to be prevented by secure channel between sensor chip and processor. This applies for all three arch.
  4. (Q. Cost effectiveness shouldn't be a criteria for L1 device. Cost will come down with volumes. ) Cost effective is still a major criteria as certification is only L1 and tender and RA are dependent on cost only. Actually this becomes cycle, you have lower BOM you get more order and thus reduce BOM again by qty. Now for users who want more security and ready to pay higher cost , I can have second model as L1(+) with HSM, secure boot processor, TPM certification and also live finger detection. (unfortunately TPM and Live Finger detection are not included in L1)
  5. (Q. TEE and Hardware keystore are two different things. TEE will not protect keys, it will only ensure execution of trusted components in memory. Hardware keystore is responsible for key protection and biometric signature.) Agree with this, But TEE does not mean secure boot, If someone loads wrong FW and it cannot call my HSM IC, what it will do? It cannot make PID data.
  6. (Q. A device cannot qualify for L1, unless there is a secure processor or secure access module with TRNG and sign capabilities. Anything less than Secureboot+TEE+HardwareKeystore-with-sign is only a L0+ device) TRNG and signing are job of HSM. It does contain all of this as I had explain above (HSM Module).

 

This discussion I had started to jointly analyze the architecture of various possible options. The secure boot or equivalent is good for first two but does not provide any additional sec with HSM. Same way Key security is also at diff level, L1(-) key in encrypted data can be broken so as security module of IC (as this has happened in past). The key security is not backed by standards and Lab  tests in case of L1(-) and L1 (for few single chip solutions).

 

Requesting other members to provide inputs, there is no word from IC mfgs.

 

Lets see what UIDAI and STQC team decides on specs and be ready with multiple options.

 

Best Regards

Ketan Upadhyay

+91 9327208489 


On Monday, July 17, 2017 at 11:29:37 PM UTC+5:30, Jyjesh Thayyil wrote:

Netaji Rao

unread,
Oct 8, 2017, 5:52:29 AM10/8/17
to aadha...@googlegroups.com

If the design is to load entire biometric module from ROM (of HSM), then that itself qualifies for secureboot. No issues there. In that case, biometric module can never get updates, that's vendor choice.

Privatekey in an encrypted flash doesn't qualify for Hardware-keystore. Where will decryption of these keys taken place? Where are the decryption keys stored?
It is nothing more than a L0 device with an embedded processor.


Thanks,
Netaji Rao D

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.
To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Netaji Rao

unread,
Oct 8, 2017, 6:12:14 AM10/8/17
to aadha...@googlegroups.com

//Biometric module does not require to be secure as it is any way available in open and anybody can use image extractor. The criteria in L0 and L1 is signing. Even if bio module is secure but the private key is compromised, what is the use. The importance is to keep key secure and sign only valid data.//
This understanding is not correct. If the biometric module is not loaded through secureboot, that itself can generate and inject biometrics. Secure channels won't help.

//But TEE does not mean secure boot, If someone loads wrong FW and it cannot call my HSM IC, what it will do? It cannot make PID da//
Please do not assume that none can call HSM.  Wrong FW doesn't mean a competitor's firmware. You own unsigned firmware is also a wrong firmware from trust perspective. An untrusted device is as good as an unsecured device.




To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

--


Thanks,
Netaji Rao D

ketan

unread,
Oct 8, 2017, 11:30:52 AM10/8/17
to Aadhaar Registered Devices Discussion Group

(//Biometric module does not require to be secure as it is any way available in open and anybody can use image extractor. The criteria in L0 and L1 is signing. Even if bio module is secure but the private key is compromised, what is the use. The importance is to keep key secure and sign only valid data.// àThis understanding is not correct. If the biometric module is not loaded through secureboot, that itself can generate and inject biometrics. Secure channels won't help.)

  • Unsecure processor module can be loaded with firmware with image capture and extractor, but without crypto handshake with HSM in cannot inject the biometrics. By loading this firmware valid PID cannot be generated as signing from HSM is not possible. Pl also do not doubt on crypto mechanism, till date it is unbroken and trusted and used in all HSM including being used in secure boot itself and device key signing.

 

(//But TEE does not mean secure boot, If someone loads wrong FW and it cannot call my HSM IC, what it will do? It cannot make PID da//

Please do not assume that none can call HSM (can you pl share any case where HSM call is compromised anywhere in world ? it is being used since many years and on multiple platform and format. Till now it is most trusted and used everywhere).  Wrong FW doesn't mean a competitor's firmware. You own unsigned firmware is also a wrong firmware from trust perspective. An untrusted device is as good as an unsecured device.)

  • This Is most ruled out and argument on the shake of just argument. The manufacture is signing key and is responsible. If the firmware is shared by Mfg, why to go in hassle of tampering, just get the key signed from Management server, because logic is known and documented by UIDAI in public domain. So let us not blame and doubt manufacturer. In this case management server and updates everything should be removed from control of Mfg. The trust is required in only signing of BS and if it is maintained and biometric is submitted with proper crypto handshake (same as security module in single chip) there is no problem.

 

The definition required in case of dual processor architecture, which processor should be secure boot and what is secure boot (there is no standard and it name differs for diff manufacturer with same logic). Same way just hardware key-store without any standards are not clear. The encrypted key on flash is hardware key-store as this are hardware and cannot be denied. Again about TEE it is just description and not standard.

 

On other specific question by Netaji (Privatekey in an encrypted flash doesn't qualify for Hardware-keystore. Where will decryption of these keys taken place? Where are the decryption keys stored?):- Regarding details on decryption of encrypted private keys and key used for decryption, these are protected by secure boot, and are part of FW and HW of IC.

 

Let’s discuss technical points and advantage and drawbacks. The decision should not be from us but from UIDAI and STQC team.

 

During working with multiple architecture and prototypes, our team has discovered few missing details in specs and in this absence we can put our all three diff versions as discussed till now and can pass all required test criteria. If saying L1(-) or L0(+) does not make any diff if it gets test passed and certified. This can also be most cost effective solution. For the users who want highest security it could be more secure second model.

 

Best Regards

Ketan Upadhyay

+91 9327208489 


On Monday, July 17, 2017 at 11:29:37 PM UTC+5:30, Jyjesh Thayyil wrote:

Netaji Rao

unread,
Oct 8, 2017, 12:09:22 PM10/8/17
to aadha...@googlegroups.com

Secureboot in UIDAI-L1 device context is to verify and load only manufacturer signed firmware/software where root of trust is established from read-only memory.

Please read all my comments in connection with above definition. 
A simple CRC/checksum check of firmware is not secureboot, in L1 device.


//Pl also do not doubt on crypto mechanism, till date it is unbroken and trusted and used in all HSM including being used in secure boot itself and device key signing.//
This is in case of single chip solution (HSM only) and shouldn't have any issues. 
My comments were about other solutions where biometric module talks to Hardware-keystore for signing.


Thanks,
Netaji Rao D


--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Shashank...@microchip.com

unread,
Oct 9, 2017, 1:39:55 AM10/9/17
to aadha...@googlegroups.com

Hi all,

 

               It has been a very engaging discussion regarding L1 compliance. The views by Ketanji, Netaji, Hirenji, Pratikji and others have been very informative. Thanks a lot for the information shared.

 

               Brief introduction – I head the technical support activities in the space of cryptography and security implementation for Microchip Technologies in the ASEAN region (India, Indonesia, Thailand, etc.).

 

I am working on Aadhaar L1 solutions with a few customers but this post is not about our solution or part numbers.

I would like to restrict my inputs regarding the current discussion and a call-to-action as technology providers to the government.

 

·        As rightly pointed out by esteemed members mentioned above, secure boot and TEE are completely different and most importantly – independent aspects of a security design

·        Secure Boot requires a so-called immutable root à The first level bootloader should be unchangeable – the most common way to implement this is thru ROM codes like a lot of semiconductor vendors do. But that is just one of the requirements.
Another very important requirement is the fact that the application image (in case of a monolithic firmware) or image components (in case of a rich OS like *nix-based OS) should be signed and (optionally) encrypted using separate keys. This key (or these keys) should either be housed in an user-unreadable location inside the ROM (the most common implementation) or inside an HSM – the host-HSM interface should mandatorily be session-based else you run the risk of key leakage thru a probe attack. The first level bootloader is responsible for verifying the signed image (and decrypting the encrypted image if applicable).

I believe UIDAI has mandated secure boot hence any topology that violates the any of the above basic requirements may need to be re-looked at. Semiconductor vendors also generally provide other “secure boot” provisions like a key-verifying key (KVK) – but the above basic reqs should be met at the minimum to qualify a “secure boot” capability.

·        TEE or Trusted Execution Environment is a completely different ball-game. TEE refers to a hardware-isolated “environment” that runs in parallel to the non-trusted part of the application. The “environment” I refer to is a combination of hardware and software.
In its most common implementation, hardware isolation is achieved inside the processor core by implementing privileged instructions which are issued by a dedicated software OS or an RTOS. By erecting a strong security perimeter between the two worlds, hardware logic present in the CPU bus fabric prevents “Normal World” components from accessing “Secure World” resources. To paint an example picture for Aadhaar L1, a TEE can be a combination of a rich OS/RTOS and a secure OS/RTOS – the rich OS/RTOS runs the USB stack, the XML stack, etc. which are generally open-source codes prone to known or yet to be discovered bugs and the secure OS/RTOS runs the secure code responsible for fetching data from the camera sensor, the extraction algorithm, the crypto accelerators and most importantly the DSA and the AES encryption. What this does is even though a vulnerability is discovered and acted upon in the rich OS, the secure OS will still not be impacted and continues to not only preserve the secret keys and codes, but also has the capability to signal to the CPU that something has gone wrong with the rich world.

Organizations like Global Platform have laid out the guidelines for inter-operable communication between the rich OS and secure OS as well as for implementation of secure key-stores.

There are proven hardware technologies in the market today (and soon to come!) like the ARM TrustZone-A, Intel’s Trusted Execution Technology, ARM TrustZone-M (for microcontrollers), etc. that help implement a true TEE. There are also secure OSes prevalent today like the OpTEE (open source TEE ported to lot of different platforms), CoreTEE (proprietary ready-to-use secure OS), Samsung KNOX (people who are aware of the immense security involved in tech like Samsung Pay will know this).

·        There was a discussion on use of an external storage being prone to repeat decrypt attacks. With a TEE implementation detailed above, this should not be a concern as areas inside the flash/external memory are dedicated for access by the secure OS and exist in an encrypted form all the time – the key itself is inside a memory zone ear-marked for the TEE. This makes it practically impossible for someone to retrieve the secure OS or the keystore as is. This is the reason such technologies have found their applications primarily in systems with external memories.

·        As far as reverse-engineering a firmware design goes or guessing secrets go, hackers are far ahead of all of us as of today. For instance consider this company that takes pride in reverse-engineering MCUs and memory. It is not surprising to see that the list they have put up consists of products from a lot of vendors. At the same time, it is important to understand that these are products designed for cost efficiency – not for security (I speak on behalf of all vendors you see there!!).

Some of us may also have heard about Defcon hack conference where the sole goal is to reverse engineer hardware. From missile systems to access systems to voting machines, these guys have been inside (figuratively!) a lot of applications!

The sole goal of mentioning these links is to motivate all of us to provide the best possible design. For all of us, the very first thought is always to reduce the cost of build, but esteemed members – I firmly believe we should also give security its due importance. Only then, I believe we can together quell any doubts that people have about the immense potential of Aadhaar and together realize the government’s dream to make India world’s first inclusive cash-less society – inclusive being the operating word
J.

 

Thank for you the discussions on the group and hope you find the above info useful. I would be glad to participate in discussions one-on-one or on the group.

Look forward and Jai Hind!

 

Regards,

Shashank

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

 

--

You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Netaji Rao

unread,
Oct 9, 2017, 2:00:41 AM10/9/17
to aadha...@googlegroups.com
Thanks Shashank. That's an informative post.

Can you please elaborate more on TEE where code is verified, loaded and code is executed in a completely isolated environment like embedded processor? Can we assume it's a complete secure-world with no action on normal world?

Thanks,
Netaji Rao D


To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Pratik | Biomatiques

unread,
Oct 9, 2017, 2:42:51 AM10/9/17
to aadha...@googlegroups.com

Dear Shashank,

 

 

Thanks for the brief below. Do you think detailed list of test cases from UIDAI will help us identify the exact requirement and improve our design capability to incorporate the required security?

 

UIDAI can test 1 design aspect (such as secure boot) by multiple test cases (1. Bootloader location, 2. key extract/fake etc)!

 

Thanks,

With much gratitude and respect,

For Biomatiques Identification Solutions (P) Ltd.

logo guidelines-12 resized 320

Pratik Patel | VP – Global System Integration

‘Rishi House’, Nr. Kargil Chowk, Piplod, Surat – 395 007, (Guj.), INDIA

Mobile: +91 990 980 4321

Phone: +91 261 2225767

Email: pra...@biomatiques.com 

 

 

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

--

You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

 

--

You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

image001.png

Shashank...@microchip.com

unread,
Oct 9, 2017, 2:45:46 AM10/9/17
to aadha...@googlegroups.com

Hi Netaji,

 

               As I mentioned the secure OS runs in parallel to the rich OS. Both software run in a time-sliced manner. The difference is in the fashion on instruction calls at the CPU level. This implementation differs from CPU to CPU.

 

For instance, ARM TrustZone makes use of an implementation called the Secure Monitor that is responsible for switching between the secure and the non-secure world. But just the secure monitor is not enough – you need a trusted kernel (not necessarily *nix – can be simpler) which is the crux of the “secure” world. This trusted kernel is the one that is responsible for the memory space allocation for the secure OS, performing secure calls to peripherals and the CPU (using special instruction extensions specific to the CPU and the CPU bus – ARM has these extensions built into the AXI bus fabric). The Secure OS should implement drivers to access the hardware peripherals that are to be only-secure accessible like the AES, the SHA, etc. On top of this would sit the crypto engine that implements the DSA, the Global Platform key storage implementation, etc.

For a microcontroller, the equivalent is the TrustZone-M which has done away with Secure Monitor and implemented the switch logic in hardware. This will make it easier to meet the real-time requirements for which MCUs are used most commonly. TrustZone-M is a new technology and you will soon see vendors coming out with this built-in.

 

Without this kind of hardware isolation at the core level, your application code has the same level of accesses to system resources like your BSP code or you low-level drivers which makes it that much easy for vulnerabilities to (negatively) affect the system.

 

PS: I talked about ARM TrustZone only because I am comfortable with their implementation and thought it would be good to explain with an example. J

 

·       Can we assume it's a complete secure-world with no action on normal world? àI am not really sure what action is being referred to here but I would put it this way – tomorrow if someone is able to get access to your system making use of any vulnerability in software, their access will be restricted to the non-secure components only (be it the kernel access, memory space access, etc.). The secure OS would run unaffected as the privilege for this software is not restricted by user being normal user or root user but by the type of CPU accesses i.e. transactions at the bus level!

 

Regards,

Shashank

 

 

From: aadha...@googlegroups.com [mailto:aadha...@googlegroups.com] On Behalf Of Netaji Rao


Sent: 09 October 2017 11:31

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

--

You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

 

--

You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Anup Das

unread,
Oct 10, 2017, 7:58:30 AM10/10/17
to Aadhaar Registered Devices Discussion Group

Thanks everybody for this detail technical discussion and special thanks to Ketan for bringing an Architectural question.

I think we still didn’t get the concrete answer to Ketan’s question. And probably it will not be easy to give an answer if the Arch clearly does not describe the sections mentioned in the STQC Solution arch document.


I would like to bring attention to 2 Excellent UIDAI and STQC documents.

 

AADHAAR REGISTERED DEVICES , TECHNICAL SPECIFICATION - VERSION 2.0 (REVISION 2), July 2017

Page 7:


UIDAI does not mandate any specific hardware design and device providers are expected to innovate appropriate form factors for market use. Key design mandate is that registered devices MUST securely sign the biometric data, form the encrypted PID block within the RD Service and give it back to application for use within Aadhaar authentication.

Registered devices MUST ensure the following;

1. There should be no mechanism for any external program to provide stored biometrics and get it signed and encrypted.

2. There should be no mechanism for external program/probe to obtain device private key used for signing the biometrics.

 

It is important to note that it is in device provider’s interest to ensure the above two items are implemented securely since any compromise on these will result in fraudulent activities signed using the device provider key. As per IT Act it is essential for the key owners (device provider) to protect the signature key and take responsibility for any compromise.


So any Arch proposal has to be viewed in this spirit of innovation.

 

In reference to what Shashank has shared, I think we should follow what STQC guidelines says about TEE. In UIDAI/STQC spec there is definition of TEE:

Guidance to applicant for Registered Devices for UID Application, Page 23 defines TEE.


TEE Definition:

For the purposes of the registered device specification the Trusted Execution Environment (TEE) is implied in the generic sense (and not restricted to Global Platform TEE). The capabilities of the TEE

1. Support for Secure boot

2. Secure storage for keys (separate isolated hardware)

3. Support for PKI encryption and signing using RSA 2048

4. Support for symmetric encryption using AES 256 GCM

5. Support for Hashing using SHA-256

6. Support at the hardware level to isolate the key operations and biometric signing

 

Only trusted software components from the device provider can be deployed on the TEE. It is expected that PKI (or equivalent) infrastructure will be used to deploy the trusted software.

Suggested certifications for the Trusted Execution Environment include:

1. Common Criteria certification of Global Platform TEE PP

2. Common Criteria certification of Global Platform TPM 2.0 PP

3. Common criteria certification of SE PP

4. FIPS 140-2 certification of Global Platform TEE, Global Platform TPM 2.0, SE

5. EAL 3 or more is a good sign so if anyone has EAL 3 or more we can simply take their certificate and accept.

6. https://en.wikipedia.org/wiki/Trusted_execution_environment#Implementations - Also compliance to the open implementations

 

Alternatively test reports from the semiconductor vendor showing compliance to the capabilities of TEE may be furnished.


So when we say something as TEE, we must look into this definition.


Further I would like to highlight notes from STQC spec:

Page 24:


In most cases, considering the rule of thumb that states every device can be broken, a device should not try and defend against lab attack directly, but should take measures which limit the damage when a device is broken and therefore make the lab attack uneconomical.

Intent

The intent of the registered device specification is to protect against scalable hack and shack attacks and limit damage due to lab attacks.


 

So System Arch design should consider these aspects, while designing. 


And also when we give answer to feasibility of specific arch, we must keep these aspects in mind.

 

A Reference from ARM TrustZone spec:

Limitations of security solutions

All security solutions are designed to defend against only a subset of the possible attacks that they may experience. Defending against all possible attacks is an impossible task; there is always someone willing to spend a significant amount of time and money to break any security scheme using very complex attacks. A design must therefore decide which assets it wants to protect, and which of the possible attacks it wants to protect the assets against. This is perhaps the most critical part of the design process; a design that protects the wrong assets against an incorrect or incomplete list of attacks can be easily broken.

 

The UIDAI/STQC specs are excellent in this Model.

 

 

So I think our Goal should be to design L1 devices that can withstand scalable hack and shack attacks and limit damage due to lab attacks

 


I have two questions to Ketan.

 What are the limitations in your ARM9 Chip (you mentioned as TEE) that you need an External Flash to store Keys?

 And how adding External Flash going to close those limitations?


May be these two answers can further help us to better understand the Arch.

 

Thanks,

Anup

ketan

unread,
Oct 25, 2017, 5:27:52 AM10/25/17
to Aadhaar Registered Devices Discussion Group

Thanks all for participating in detail discussion. During this discussion we also get some diff point of view.

While working in detail on multiple possible options this got noticed.

 

The main problem from point of designer is there is no mandate or requirement of specific certification or testing process.

For L0 devices we have detailed testing process, including native code requirement and memory dump test etc.

 

I suppose we have clear understanding on at-least one point is, if OTA updates are required, The CPU must support Secure-boot. However OTA update is not mandated by UIDAI (till now) and in this case the guidelines also can be achieved by ROM and OTP-ROM as it does not have any chance of tempering. This does not match TEE definition point of secure boot, but the code is tamper proof. What is the view of UIDAI on this specific point?

 

The earlier architecture case we have discussed, still can be passed as per input of Mr. Shashank , if the encryption are strong enough. The point here could be how testing agency will simulate attacks on this encrypted storage, which is accessible for data reading, but the encryption key and even mechanism is unknown.

 

Here I am presenting second option diagram, (This will enable many more CPU to pass L1 requirements) (attached)


 

Here CPU has security module and secure boot, the key-storage is also external (same like earlier) additionally even RAM is also external. The interested case here is by design of manufacture there is no provision to extract or insert templates (biometrics data for Iris), but as the RAM is external and in standard package, it can be manipulated or tampered with and can be used to extract FMR or Insert FMR (need to monitor memory for FMR data only). Most of the compiled program on CPU has fixed memory location for shared variable and once located can be manipulated. Interesting point here is how this will be tested or evaluated by UIIDAI/STQC, as to make test rig for these type of design specific attacks are difficult.

Above design fulfills all the point of TEE definition given in documents.

 

Many chips has very good security futures, but the detailed working of same is not shared with manufacturer (to protect security, they have this policy). Does UIDAI planning to take undertakings instead of testing and evaluation? If, so the mfgs are signing undertakings without full detailed information. If manufacturer works on architecture shown above or earlier (which was even better secure than this) and provides undertakings, will it get L1 certification?

 

Why not UIDAI add some guidelines like, restriction on external storage and RAM without TPM. Device manufacture to submit details on security module supported by any good standards (or Chip manufacture share details with UIDAI, if they do not want to share with mfg, as it could be used against competitor or due to security policy of chip mfg) and prove beyond doubt about secure storage of key and biometric data protection

 

Additional testing procedure and guidelines for submitting testing  rig by manufacture is also required. As if asked to prove, manufacture will provide only positive test rigs and not full capacity attack test rigs.

 

Regards

Ketan Upadhyay

+91 9327208489

 


Pratik | Biomatiques

unread,
Oct 25, 2017, 7:09:32 AM10/25/17
to aadha...@googlegroups.com

Dear Anup & UIDAI Team,

 

 

Greetings from Biomatiques and wishing all a Happy New Year J

 

As per your email below regarding TEE Definition and its applicable compliance (highlighted in Green below), point 2 mentioned (as highlighted in yellow below), separate hardware can be used for secure key storage.

Can I expect UIDAI team to comment on this??? This also means we can use external memory compliant to FIPS or other equivalent standards in our designs as suggested by Ketan and other colleagues!

 

Thanks,

With much gratitude and respect,

For Biomatiques Identification Solutions (P) Ltd.

logo guidelines-12 resized 320

Pratik Patel | VP – Global System Integration

‘Rishi House’, Nr. Kargil Chowk, Piplod, Surat – 395 007, (Guj.), INDIA

Mobile: +91 990 980 4321

Phone: +91 261 2225767

Email: pra...@biomatiques.com 

 

 

--

You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.
To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

image003.png

Netaji Rao

unread,
Oct 25, 2017, 7:39:57 AM10/25/17
to aadha...@googlegroups.com
My understanding:

The Hardware keystore should also be capable of biometric signing (from latest ppt from UIDAI) and this keystore+signing should be isolated (from TEE definition in green below).


Thanks,
Netaji Rao D


To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

natekar srinivas

unread,
Nov 22, 2017, 1:51:56 AM11/22/17
to Aadhaar Registered Devices Discussion Group
Dear All.

Whoever is completed with  L1- Solution Architect Document Pls share on below Id's. 



Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

E-Mail- Srinivas...@uidai.net.in  

natekar srinivas

unread,
Mar 14, 2018, 12:46:35 PM3/14/18
to Aadhaar Registered Devices Discussion Group

Dear All,

 

Please be informed that  L1 workshop on Registered Devices is planned on 20th March,2018  at UIDAI Tech Centre, Bangalore.

 

Workshop is ONLY for those Device Vendors who are interested in L1 Registered devices certification. Only Technical person should be nominated for the workshop and Each company can nominate only 2 persons.

 

Pls send Participant details for Gate pass  latest by 18th EOD to Srinivas...@uidai.net.in  with below subject line.

 

Subject:-  L1 Workshop <Company Name>- Gate pass

 

Pls Note:- Request will not be accepted beyond stated date.


Venue:- 


UIDAI Tech Centre, 

NTI Layout, Tata Nagar, Kodigehalli, 

Bangalore -560092. 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

E-Mail- Srinivas...@uidai.net.in  


 


On Wednesday, 22 November 2017 12:21:56 UTC+5:30, natekar srinivas wrote:
Dear All.

Whoever is completed with  L1- Solution Architect Document Pls share on below Id's. 



Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

natekar srinivas

unread,
Mar 14, 2018, 1:23:32 PM3/14/18
to Aadhaar Registered Devices Discussion Group
Dear All,

workshop Time:- 9.30 to 12.00  


Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

E-Mail- Srinivas.natekar@uidai.net.in  




On Wednesday, 14 March 2018 22:16:35 UTC+5:30, natekar srinivas wrote:

Dear All,

 

Please be informed that  L1 workshop on Registered Devices is planned on 20th March,2018  at UIDAI Tech Centre, Bangalore.

 

Workshop is ONLY for those Device Vendors who are interested in L1 Registered devices certification. Only Technical person should be nominated for the workshop and Each company can nominate only 2 persons.

 

Pls send Participant details for Gate pass  latest by 18th EOD to Srinivas...@uidai.net.in  with below subject line.

 

Subject:-  L1 Workshop <Company Name>- Gate pass

 

Pls Note:- Request will not be accepted beyond stated date.


Venue:- 


UIDAI Tech Centre, 

NTI Layout, Tata Nagar, Kodigehalli, 

Bangalore -560092. 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

natekar srinivas

unread,
Mar 18, 2018, 10:13:49 AM3/18/18
to Aadhaar Registered Devices Discussion Group

Dear All,

 

Thanks for nominating yourself in Workshop,  Entry pass are made available kindly be in present in  2nd floor Board room by 9.20 am.

Regards, 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

soma rajanarsaiah

unread,
Mar 19, 2018, 4:04:25 AM3/19/18
to aadha...@googlegroups.com, rajan.soma, Ramesh Babu
Dear Srinivas,

Thanks for the confirmation.

Please add my colleague name also for this work shop.

Mr. Ramesh Babu and Myself will be attending the workshop tomorrow.

with regards,
Rajan Soma
Director 
Aratek Innovation Pvt Ltd.,

On Sun, Mar 18, 2018 at 7:43 PM, natekar srinivas <natekar....@gmail.com> wrote:

Dear All,

 

Thanks for nominating yourself in Workshop,  Entry pass are made available kindly be in present in  2nd floor Board room by 9.20 am.

Regards, 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

--
You received this message because you are subscribed to a topic in the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/aadhaar_rd/xsYNUbO50II/unsubscribe.
To unsubscribe from this group and all its topics, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Jyjesh Thayyil

unread,
Mar 20, 2018, 1:58:48 PM3/20/18
to aadha...@googlegroups.com
We express our sincere thanks to all who participated in today's workshop. We will soon be back with first cut L1 device specification document.

​Regards,
​Team UIDAI.


-
Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The Organisation accepts no liability for any damage caused by any virus transmitted by this email. 

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Ameya Bhagwat

unread,
Mar 26, 2018, 1:19:45 AM3/26/18
to aadha...@googlegroups.com

Hi UIDAI Team,

 

Please help us understand if the new L1 specification will also call for integration of FaceAuth SDK as there is a report saying UIDAI will start Face Auth in “fusion mode” from 1st July 2018.

 

Warm Regards,

 

Ameya


On Wednesday, 14 March 2018 22:53:32 UTC+5:30, natekar srinivas wrote:

Dear All,

 

workshop Time:- 9.30 to 12.00  

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 



On Wednesday, 14 March 2018 22:16:35 UTC+5:30, natekar srinivas wrote:

Dear All,

 

Please be informed that  L1 workshop on Registered Devices is planned on 20th March,2018  at UIDAI Tech Centre, Bangalore.

 

Workshop is ONLY for those Device Vendors who are interested in L1 Registered devices certification. Only Technical person should be nominated for the workshop and Each company can nominate only 2 persons.

 

Pls send Participant details for Gate pass  latest by 18th EOD to Srinivas...@uidai.net.in  with below subject line.

 

Subject:-  L1 Workshop <Company Name>- Gate pass

 

Pls Note:- Request will not be accepted beyond stated date.

 

Venue:- 

 

UIDAI Tech Centre, 

NTI Layout, Tata Nagar, Kodigehalli, 

Bangalore -560092. 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 


On Wednesday, 22 November 2017 12:21:56 UTC+5:30, natekar srinivas wrote:

Dear All.

 

Whoever is completed with  L1- Solution Architect Document Pls share on below Id's. 

 

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 

   

On Monday, 17 July 2017 23:29:37 UTC+5:30, Jyjesh Thayyil wrote:

Dear All,

 

Pl use this thread to provide your suggestions and queries on Level 1 compliance.

 

Regards,

Team UIDAI.

--

You received this message because you are subscribed to a topic in the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/aadhaar_rd/xsYNUbO50II/unsubscribe.

To unsubscribe from this group and all its topics, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

 

--

You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Netaji Rao

unread,
Mar 28, 2018, 5:00:16 AM3/28/18
to aadha...@googlegroups.com
Hi Team,

Is the L1 draft spec released?


Thanks,
Netaji Rao D

Jyjesh Thayyil

unread,
Apr 6, 2018, 2:08:01 PM4/6/18
to Aadhaar Registered Devices Discussion Group
Dear All,

Here is the first draft of L1 registered device specifications. We value your feedback on attached document ver 0.9.

Happy reading!!

Regards,
Team UIDAI.
 


On Wednesday, 14 March 2018 22:53:32 UTC+5:30, natekar srinivas wrote:

Dear All,

 

workshop Time:- 9.30 to 12.00  

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.



On Wednesday, 14 March 2018 22:16:35 UTC+5:30, natekar srinivas wrote:

Dear All,

 

Please be informed that  L1 workshop on Registered Devices is planned on 20th March,2018  at UIDAI Tech Centre, Bangalore.

 

Workshop is ONLY for those Device Vendors who are interested in L1 Registered devices certification. Only Technical person should be nominated for the workshop and Each company can nominate only 2 persons.

 

Pls send Participant details for Gate pass  latest by 18th EOD to Srinivas...@uidai.net.in  with below subject line.

 

Subject:-  L1 Workshop <Company Name>- Gate pass

 

Pls Note:- Request will not be accepted beyond stated date.

 

Venue:- 

 

UIDAI Tech Centre, 

NTI Layout, Tata Nagar, Kodigehalli, 

Bangalore -560092. 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 


On Wednesday, 22 November 2017 12:21:56 UTC+5:30, natekar srinivas wrote:

Dear All.

 

Whoever is completed with  L1- Solution Architect Document Pls share on below Id's. 

 

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 

   

On Monday, 17 July 2017 23:29:37 UTC+5:30, Jyjesh Thayyil wrote:

Dear All,

 

Pl use this thread to provide your suggestions and queries on Level 1 compliance.

 

Regards,

Team UIDAI.

--

You received this message because you are subscribed to a topic in the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/aadhaar_rd/xsYNUbO50II/unsubscribe.

To unsubscribe from this group and all its topics, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.
Draft L1 spec ver 0.9.pdf

Jyjesh Thayyil

unread,
May 7, 2018, 9:06:05 AM5/7/18
to Aadhaar Registered Devices Discussion Group
Dear All,

STQC have published L1 spec addendum draft document ver 0.93 requesting comments until 14th May 2018. You can find the same at 


Regards,
Team UIDAI.

Netaji Rao

unread,
May 7, 2018, 9:30:37 AM5/7/18
to aadha...@googlegroups.com
Dear Jyjesh,

This is a scanned doc, can we get a regular PDF?

Thanks,
Netaji Rao D


On Wednesday, 14 March 2018 22:53:32 UTC+5:30, natekar srinivas wrote:

Dear All,

 

workshop Time:- 9.30 to 12.00  

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 



On Wednesday, 14 March 2018 22:16:35 UTC+5:30, natekar srinivas wrote:

Dear All,

 

Please be informed that  L1 workshop on Registered Devices is planned on 20th March,2018  at UIDAI Tech Centre, Bangalore.

 

Workshop is ONLY for those Device Vendors who are interested in L1 Registered devices certification. Only Technical person should be nominated for the workshop and Each company can nominate only 2 persons.

 

Pls send Participant details for Gate pass  latest by 18th EOD to Srinivas...@uidai.net.in  with below subject line.

 

Subject:-  L1 Workshop <Company Name>- Gate pass

 

Pls Note:- Request will not be accepted beyond stated date.

 

Venue:- 

 

UIDAI Tech Centre, 

NTI Layout, Tata Nagar, Kodigehalli, 

Bangalore -560092. 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 


On Wednesday, 22 November 2017 12:21:56 UTC+5:30, natekar srinivas wrote:

Dear All.

 

Whoever is completed with  L1- Solution Architect Document Pls share on below Id's. 

 

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 

   

On Monday, 17 July 2017 23:29:37 UTC+5:30, Jyjesh Thayyil wrote:

Dear All,

 

Pl use this thread to provide your suggestions and queries on Level 1 compliance.

 

Regards,

Team UIDAI.

--

You received this message because you are subscribed to a topic in the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/aadhaar_rd/xsYNUbO50II/unsubscribe.

To unsubscribe from this group and all its topics, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

kirubakaran

unread,
May 8, 2018, 8:19:17 AM5/8/18
to aadha...@googlegroups.com

Hi There,

 

Please find the below doubts from this draft document

 

 

Section 6. Secure Boot and Secure Upgrade

 

How STQC will validate whether our device actually does secured boot and secured software upgrade ?

Whether Device Provider's self certification will be enough  or whether STQC have some test cases for secured boot and secured s/w upgrade which will be executed as part of certification test?

Whether is it allowed to upgrade TEE secured Software for the in-field devices or not ?

 

Section 10. Reference design

 

There are two diagrams in this section. And, both explains about 2 chip solution.

If possible, can you please share the reference design for a single chip solution?

 

Section 11

 

1. what is the purpose of Sign1 ? (this section in draft explains about it. But it’s not used)

2. How management server can validate IDHash since the CI(k) is part of the device?

 

Thanks,

Kiruba


On Wednesday, 14 March 2018 22:53:32 UTC+5:30, natekar srinivas wrote:

Dear All,

 

workshop Time:- 9.30 to 12.00  

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.



On Wednesday, 14 March 2018 22:16:35 UTC+5:30, natekar srinivas wrote:

Dear All,

 

Please be informed that  L1 workshop on Registered Devices is planned on 20th March,2018  at UIDAI Tech Centre, Bangalore.

 

Workshop is ONLY for those Device Vendors who are interested in L1 Registered devices certification. Only Technical person should be nominated for the workshop and Each company can nominate only 2 persons.

 

Pls send Participant details for Gate pass  latest by 18th EOD to Srinivas...@uidai.net.in  with below subject line.

 

Subject:-  L1 Workshop <Company Name>- Gate pass

 

Pls Note:- Request will not be accepted beyond stated date.

 

Venue:- 

 

UIDAI Tech Centre, 

NTI Layout, Tata Nagar, Kodigehalli, 

Bangalore -560092. 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 


On Wednesday, 22 November 2017 12:21:56 UTC+5:30, natekar srinivas wrote:

Dear All.

 

Whoever is completed with  L1- Solution Architect Document Pls share on below Id's. 

 

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 

   

On Monday, 17 July 2017 23:29:37 UTC+5:30, Jyjesh Thayyil wrote:

Dear All,

 

Pl use this thread to provide your suggestions and queries on Level 1 compliance.

 

Regards,

Team UIDAI.

--
You received this message because you are subscribed to a topic in the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/aadhaar_rd/xsYNUbO50II/unsubscribe.

To unsubscribe from this group and all its topics, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

--

You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

Kiran.Penneru

unread,
Jun 25, 2018, 1:35:09 AM6/25/18
to aadhaar_rd, Vivek Raghavan
Dear UIDAI  L1 Tech Support Team,

         Kindly clarify our below query on L1 Sensor Integration requirements.

         These are Possible Biometric Sensor Integrations of L1 Devices.
         Kinldy confirm what tests are mandatory / optional / not required.

         1.  L1 Device with Existing STQC Certified Biometric Sensor.
                a)  Physical and Electrical Lab Tests  - Mandatory / Optional ?
                b)  IQT Test                                   - Mandatory / Optional ?
                c)  Final 5000 FRR Test                    - Mandatory / Optional ?
                d)  L1 Special FRR Test                    - Mandatory / Optional ?

         2.  L1 Device with Existing STQC Certified Biometric Sensor but with Different Extractor Algorithm.
                a)  Physical and Electrical Lab Tests  - Mandatory / Optional ?
                b)  IQT Test                                   - Mandatory / Optional ?
                c)  Final 5000 FRR Test                   - Mandatory / Optional ?
                d)  L1 Special FRR Test                   - Mandatory / Optional ?

         3.  L1 Device with Existing STQC Certified Biometric Sensor with Embedded Extractor Variant of Same Algorithm.
                a)  Physical and Electrical Lab Tests  - Mandatory / Optional ?
                b)  IQT Test                                   - Mandatory / Optional ?
                c)  Final 5000 FRR Test                   - Mandatory / Optional ?
                d)  L1 Special FRR Test                   - Mandatory / Optional ?

         4.  L1 Device with another Biometric Sensor (PIV Certified) and required minex certified algorithm.
                a)  Physical and Electrical Lab Tests  - Mandatory / Optional ?
                b)  IQT Test                                   - Mandatory / Optional ?
                c)  Final 5000 FRR Test                   - Mandatory / Optional ?
                d)  L1 Special FRR Test                   - Mandatory / Optional ?

        PCH Certification of L1 Device is any how mandatory.        

        Kindly clarify on the above so that it will be helpful to understand if there is any advantage using existing Stqc Biometric Sensors
        for L1 Sensor Integrations.

Best Regards,
Kiran Penneru
Techshino Technology India Private Ltd

------------------------------------------------------------------
From:kirubakaran <kirubakara...@techrizes.net>
Time:2018 May 8 (Tue) 17:49
Subject:RE: [aadhaar_rd] Re: Suggestions and Queries on L1 compliance - Draft L1 specs

Sanjith Sundaram

unread,
Jun 25, 2018, 2:39:58 AM6/25/18
to Aadhaar Registered Devices Discussion Group
Hi Kiran,

While we wait for clarity on your questions, isnt MINEX certified extractor mandatory for STQC certification? From the options provided in your mail, it seems like non-MINEX certified extractor is also being suggested. Can you please clarify for better understanding of everyone?

Regards,
Sanjith Sundaram
------------------------------------------------------------------
Time:2018 May 8 (Tue) 17:49
Subject:RE: [aadhaar_rd] Re: Suggestions and Queries on L1 compliance - Draft L1 specs

Hi There,

 

Please find the below doubts from this draft document

 

 

Section 6. Secure Boot and Secure Upgrade

 

How STQC will validate whether our device actually does secured boot and secured software upgrade ?

Whether Device Provider's self certification will be enough  or whether STQC have some test cases for secured boot and secured s/w upgrade which will be executed as part of certification test?

Whether is it allowed to upgrade TEE secured Software for the in-field devices or not ?

 

Section 10. Reference design

 

There are two diagrams in this section. And, both explains about 2 chip solution.

If possible, can you please share the reference design for a single chip solution?

 

Section 11

 

1. what is the purpose of Sign1 ? (this section in draft explains about it. But it’s not used)

2. How management server can validate IDHash since the CI(k) is part of the device?

 

Thanks,

Kiruba


On Wednesday, 14 March 2018 22:53:32 UTC+5:30, natekar srinivas wrote:

Dear All,

 

workshop Time:- 9.30 to 12.00  

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.



On Wednesday, 14 March 2018 22:16:35 UTC+5:30, natekar srinivas wrote:

Dear All,

 

Please be informed that  L1 workshop on Registered Devices is planned on 20th March,2018  at UIDAI Tech Centre, Bangalore.

 

Workshop is ONLY for those Device Vendors who are interested in L1 Registered devices certification. Only Technical person should be nominated for the workshop and Each company can nominate only 2 persons.

 

Pls send Participant details for Gate pass  latest by 18th EOD to Srinivas...@uidai.net.in  with below subject line.

 

Subject:-  L1 Workshop <Company Name>- Gate pass

 

Pls Note:- Request will not be accepted beyond stated date.

 

Venue:- 

 

UIDAI Tech Centre, 

NTI Layout, Tata Nagar, Kodigehalli, 

Bangalore -560092. 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 


On Wednesday, 22 November 2017 12:21:56 UTC+5:30, natekar srinivas wrote:

Dear All.

 

Whoever is completed with  L1- Solution Architect Document Pls share on below Id's. 

 

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 

   

On Monday, 17 July 2017 23:29:37 UTC+5:30, Jyjesh Thayyil wrote:

Dear All,

 

Pl use this thread to provide your suggestions and queries on Level 1 compliance.

 

Regards,

Team UIDAI.

--
You received this message because you are subscribed to a topic in the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/aadhaar_rd/xsYNUbO50II/unsubscribe.

To unsubscribe from this group and all its topics, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+unsubscribe@googlegroups.com.

Netaji Rao

unread,
Jun 25, 2018, 6:21:25 AM6/25/18
to aadha...@googlegroups.com
Hi Sanjith,

Minex certified extractor was mandatory when the auth devices certification was started initially, when Provisional certificate had to be issued without FRR.

Now STQC is conducting a mini-FRR with 100 subjects as part of provisional Certification. Final 5000 subjects FRR is anyway mandatory for final Certification. So now ISO 19794-2 extractor that is interoperable and passes FRR tests is good for Certification.

Fingerprint Authentication device specifications given in 2012, were with respective to provisional certification without FRR tests.


Thanks,
Netaji Rao D

------------------------------------------------------------------
From:kirubakaran <kirubakara...@techrizes.net>
Time:2018 May 8 (Tue) 17:49
Subject:RE: [aadhaar_rd] Re: Suggestions and Queries on L1 compliance - Draft L1 specs

Hi There,

 

Please find the below doubts from this draft document

 

 

Section 6. Secure Boot and Secure Upgrade

 

How STQC will validate whether our device actually does secured boot and secured software upgrade ?

Whether Device Provider's self certification will be enough  or whether STQC have some test cases for secured boot and secured s/w upgrade which will be executed as part of certification test?

Whether is it allowed to upgrade TEE secured Software for the in-field devices or not ?

 

Section 10. Reference design

 

There are two diagrams in this section. And, both explains about 2 chip solution.

If possible, can you please share the reference design for a single chip solution?

 

Section 11

 

1. what is the purpose of Sign1 ? (this section in draft explains about it. But it’s not used)

2. How management server can validate IDHash since the CI(k) is part of the device?

 

Thanks,

Kiruba


On Wednesday, 14 March 2018 22:53:32 UTC+5:30, natekar srinivas wrote:

Dear All,

 

workshop Time:- 9.30 to 12.00  

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.



On Wednesday, 14 March 2018 22:16:35 UTC+5:30, natekar srinivas wrote:

Dear All,

 

Please be informed that  L1 workshop on Registered Devices is planned on 20th March,2018  at UIDAI Tech Centre, Bangalore.

 

Workshop is ONLY for those Device Vendors who are interested in L1 Registered devices certification. Only Technical person should be nominated for the workshop and Each company can nominate only 2 persons.

 

Pls send Participant details for Gate pass  latest by 18th EOD to Srinivas...@uidai.net.in  with below subject line.

 

Subject:-  L1 Workshop <Company Name>- Gate pass

 

Pls Note:- Request will not be accepted beyond stated date.

 

Venue:- 

 

UIDAI Tech Centre, 

NTI Layout, Tata Nagar, Kodigehalli, 

Bangalore -560092. 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 


On Wednesday, 22 November 2017 12:21:56 UTC+5:30, natekar srinivas wrote:

Dear All.

 

Whoever is completed with  L1- Solution Architect Document Pls share on below Id's. 

 

 

 

Regards,

 

Srinivas Natekar
Project Manager - Authentication

UNIQUE IDENTIFICATION AUTHORITY OF INDIA

L- 080-23099243, M-9620919782.

 

 

   

On Monday, 17 July 2017 23:29:37 UTC+5:30, Jyjesh Thayyil wrote:

Dear All,

 

Pl use this thread to provide your suggestions and queries on Level 1 compliance.

 

Regards,

Team UIDAI.

--
You received this message because you are subscribed to a topic in the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/aadhaar_rd/xsYNUbO50II/unsubscribe.

To unsubscribe from this group and all its topics, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to

--
You received this message because you are subscribed to the Google Groups "Aadhaar Registered Devices Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aadhaar_rd+...@googlegroups.com.

To post to this group, send email to aadha...@googlegroups.com.
Visit this group at https://groups.google.com/group/aadhaar_rd.

TechMax

unread,
Jul 5, 2018, 4:00:35 AM7/5/18
to Aadhaar Registered Devices Discussion Group
Hello All,
Can Anyone Provide Us Full L1 Device Specifications? L1 Device Specification Finalized?

-Thanks
Bhavin Ahir
Reply all
Reply to author
Forward
0 new messages