Using nvmem_read to get smart_config results, then getting the key

Hi,

1. The devices will not have prior knowledge on whether the encryption is used or not. Hence it is important that the user enables encryption on the CC3000 as well as on the Smart Phone SmartConfig application(and then provides the key). In this way both are aware of the scheme of things that follow.

2. Is it the 'profileArray' that you are referring to? The array is padded by 0xFF after you read the values from NVMEM, and the padded value 0xFF starts from profileArray[46] onwards, which at that point is not used. This should be fine. We are concerned about the value at profileArray[45]. This, if it is 0, then we take the key length as the one placed at profileArray[14]. If not, we would keep it at max value of 32 in most cases. 

Thanks & Regards,
Raghavendra

Thank you for replying, Raghavendra, however you seem to have misunderstood my questions.  Let me see if I can clarify what I mean.

1. I am running the Basic WiFi Application that was distributed by TI as an example.  It is designed to go with the iPhone app that is also distributed by TI.  All of the tutorials that TI publishes describe using these two pieces together.  In the Host Application, encryption is assumed.  In the iPhone App, encryption is not implemented.  Even when I enter an AES key in the App, the information extracted by the host from the CC3000 is not encrypted.  So my questions are: Why are these two pieces which were made to work together NOT "both aware of the scheme of things that follow"?  Why can't I use encryption from the iPhone App?

2. Lets talk about the profileArray buffer.  You are wrong about where the padding starts from.  I don't know where you get the index 46.  Are you working with a different chip?  Are you assuming that the lengths of the SSID and the password are always fixed?  That seems like an unreasonable assumption.  I have verified and am sure that the index where 0xFF padding starts is given by *length of SSID* + *length of password* + 3.  The distributed code looks for the '\0' marker at *length of SSID* + 3 + 31.  Unfortunately, this fails because there is no '\0' flag present in profileArray.

I observe the layout of profileArray as follows (with unencrypted password) :

1 byte: length of SSID

n bytes: SSID

1 byte: length of password

1 byte: security type

m bytes: password

(I am unable to determine what happens when the password is encrypted because I cannot get the iPhone app to encrypt it in the first place, as I mentioned above)

The code that TI distributed to parse profileArray expects the following format:

1 byte: length of SSID

n bytes: SSID

1 byte: security type

32 bytes: password and length encoded as you described.

My questions on the second point are: Why do the Host Driver code and the CC3000 disagree on the format of this profileArray?  How can I find documentation about how the CC3000 really behaves?

Hi,

It is strange to know that your setup does not work with Encryption. Let me see if this indeed is the behavior.

Regarding the parfileArray pattern, I'm sorry if my description was not clear. I missed mentioning a fixed SSID of length 11 and a key length that was relatively smaller in length(such that total length stays within 67), so that this would clearly show the way how 0xFF is padded at the end of 32 byte password field. I understand that we are making the same point. 

But in case where the password is less than 32 bytes, we are padding the remaining bytes in the password filed with '\0'. And in case where the password is 32 bytes, we would not be able to find a '\0', and in this case, we hit the below condition and set the length to 32.

else
  {
   keyLen = 32;
  }

The code also expects "1 byte: length of password" and checks for it as below:

 if (profileArray[profileArray[0] + 1] > 16)
    aes_decrypt((UINT8 *)(decKeyPtr + 16), key);

Thanks & Regards,
Raghavendra 

The fact that you are not addressing most of my questions leads me to think that you are not reading my posts. Maybe English is not your first language?  I've come to expect much better customer service from TI.  

I'm disappointed that you can't offer any insight into why Ti's iPhone App does not work with encryption.  Maybe someone else can answer that one.

I still want answered to these two questions:

Why do the Host Driver code and the CC3000 disagree on the format of profileArray?

How can I find documentation about how the CC3000 really behaves?

You said:

Raghavendra Shenoy Mathav said:

in case where the password is less than 32 bytes, we are padding the remaining bytes in the password filed with '\0'

Even though I already said:

Luke Davidson2 said:

 there is no '\0' flag present in profileArray

To be clear, I am using a short password (10 bytes), so if what you are saying were true, then I would see some '\0' bytes as padding.

You seem to not understand that I am encountering two (2) separate paradigms of behavior.

First: The way the Host Driver Code expects profileArray to be formatted.  This is also the way that you keep insisting it behaves.  This includes the zero padding with passwords less than 31 bytes, and the length being conditionally encoded into the first of the 32 bytes where the password resides.

Second: The way my CC3000 actually formats the profileArray buffer. (as I have determined through CCS's memory inspection tool)  This includes padding with 0xFF, and the length of the password being represented outside of the password buffer itself. (even when I use Smart Config with a password of 32 bytes the length is still explicitly present)

So, to restate my questions above:

Why is there a difference between what I see, and what I was told I would see?

Hi,

I completely understand what you are referring to here. I understand that you are observing a different pattern in profileArray buffer, whereas it should have matched the code in the wlan.c file.

To answer your question, we do not have such a scenario captured anywhere in our documentation. This may be because we have never come accross such a scenario so far.

In my test scenario, I do see '\0' padding after the password. But in youe test case you are not seeing this. This means that we are doing certain things differently. And also please consider the fact that your data stream is not encrypted, and I believe that you may be seeing a different pattern in profileArray buffer due to this.

Can you please help to clarify the below question?

At what point are you using the CCS's memory inspection tool to read the value in profileArray buffer? Are you reading it right after a call to nvmem_read(NVMEM_SHARED_MEM_FILEID, SMART_CONFIG_PROFILE_SIZE, 0, profileArray); ? If yes, then you would not see the passwords padded with '\0', because you are still seeing the encypted stream.

You will see the password padded with '\0' only after you complete the call to 'aes_decrypt'. After this you will also see the length in the first byte of the password field, as expected by the host driver code.

Please let me know if I am still missing something here.

Thanks & Regards,
Raghavendra

I am using the password without a call to aes_decrypt(), because, like I said, the password is present in plain text before the attempt to decrypt, and afterwards it is just garbage.

Before decryption I have these 32 bytes in the password field:

70 61 73 73 77 6F 72 64 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32

 p  a  s  s  w  o  r  d  9  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9  0  1  2

The 8 character password 'password' is clearly visible just as it  was when I typed it into the phone.  The rest of the characters are the left over buffer contents from the last time I tested a long password.

After running encryption, I see this:

4F 09 B4 0C EB FF A1 08 66 30 37 FA 26 0F 9E 85 E7 86 1E B5 43 54 76 8E CF D9 5C E8 0F 01 E7 4C

Which is just garbage.  But, you'd expect to get garbage when you decrypt unencrypted data.

I don't know if it makes a difference, but when I call nvmem_read_sp_version(), it returns to me 0x01, 0x0A.

As far as I can interpret, that means I have package id 1 and build number 10.

Hi Luke,

The function wlan_smart_config_process would end up giving unexpected results if the password is unencrypted. That is why we have the the complete function  wlan_smart_config_process inside the compilation flag 'CC3000_UNENCRYPTED_SMART_CONFIG'. In this particular case, the connection would go through if 'CC3000_UNENCRYPTED_SMART_CONFIG' is defined and if a call to wlan_smart_config_start(0) is made.

If not, can you please try this with another phone where the encryption works? You can see the correct pattern in profileArray.

The Service pack version should not really matter. But I would suggest you to move to the latest version (1.26).

Thanks & Regards,
Raghavendra