This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Connecting to AWS Cognito

I am trying to modify the https_client example from ncs\nrf\samples\nrf9160\https_client on Thingy91 so that it will retrieve an authentifcation token from AWS Cognito.
So far I have changed the certificate to Amazon Root CA 1, changed the URL to "cognito-idp.eu-central-1.amazonaws.com" instead of "google.com" and sending the following data to the server (sensitive data blanked here) instead of HTTP_HEAD as in the example:
    "POST / HTTP/1.1\r\n" \
    "Host: cognito-idp.eu-central-1.amazonaws.com\r\n" \
    "Content-Type: application/x-amz-json-1.1\r\n" \
    "X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth\r\n" \
    "Content-Length: 149\r\n" \
    "\r\n" \
    "{\"AuthParameters\": {\"USERNAME\": \"xxxxxxxxx\", \"PASSWORD\": \"xxxxxxxxxxxx\"}, \"AuthFlow\": \"USER_PASSWORD_AUTH\", \"ClientId\": \"xxxxxxxxxxxxxxxxxxxxxxxxxx\"}"

When I send this payload to AWS cognito using openssl s_client on a PC, I get the authentification token, but running on Thingy I just receive an empty reply from the server (zero bytes received, further reads produce an error: -1).
I substituted the certificate for the old one which is not in the verification chain of the cognito server and already the connect command fails, so I can rule out that the certificate is wrong.
I changed Content-Length to a value less than 149 and then I get a BAD REQUEST reply. If I change to something larger than 149, recv will block (which is to be expected as the server is still waiting for the missing payload).
I also tried to wait 2s between send and recv, but I still got an empty response from the server.
Any ideas what to do?

Parents
  • Hello, 

    Have you verified the connection to the server? While doing HTTP requests from servers, we have seen that servers respond with too many certificates causing an issue. The reason for this is that the nRF9160 only has 2k of RAM for certificates, while a web server might return 16k. This explains why you are successful on your PC. 

    Can you please provide a modem trace? This way we can see what actually happens in the communication between server and device.

    Thank you!

    Kind regards,
    Øyvind

  • The COM port disappears from time to time so Trace Collector loses its connection or cannot establish it in time. I have put the application in a reboot loop, but so far I could not capture a useful trace. Is there a possibility to buffer the trace locally on the device?

    I also extracted the server certificate from openssl s_client:

    -----BEGIN CERTIFICATE-----
    MIIFlTCCBH2gAwIBAgIQA/1rKlkx232pEo+fr+APhDANBgkqhkiG9w0BAQsFADBG
    MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRUwEwYDVQQLEwxTZXJ2ZXIg
    Q0EgMUIxDzANBgNVBAMTBkFtYXpvbjAeFw0xOTA4MTkwMDAwMDBaFw0yMDA5MTkx
    MjAwMDBaMDExLzAtBgNVBAMTJmNvZ25pdG8taWRwLmV1LWNlbnRyYWwtMS5hbWF6
    b25hd3MuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqozHRU3v
    Fx0zm2zjVmtNPLBtP7xx5ZNhxgEg8BqN/2XRcBUHprvmMIEJO9qXJaBYl6YJVgP/
    +CfI2GeBqybda48XOWSD1r1lGifv2ykw2G+J2kyFnpYYZsDM30U1wv3BPd3uDtQ2
    hVyE0f8l5/bukYfT/Mn9Tc4Ac5OCWSKyic/fl8TC0f1MigyMWGbxHdRMe2iwqDMF
    NdfuABkypT5rXfWWYT2CjYhKsrLvwQxNz9BH661nSvAGuIuEXa52XxAVQQb3tjCB
    qFpEWGeqruH+TcF5n4rDmf7BnFVwltHRCRihNpODKlCyzUAmPHFNBJN8sdYHs+ox
    2pdKXZuzMLGnowIDAQABo4ICkjCCAo4wHwYDVR0jBBgwFoAUWaRmBlKge5WSPKOU
    ByeWdFv5PdAwHQYDVR0OBBYEFH7/HkqyUHufYp4ai6JFLYyOwkTIMDEGA1UdEQQq
    MCiCJmNvZ25pdG8taWRwLmV1LWNlbnRyYWwtMS5hbWF6b25hd3MuY29tMA4GA1Ud
    DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwOwYDVR0f
    BDQwMjAwoC6gLIYqaHR0cDovL2NybC5zY2ExYi5hbWF6b250cnVzdC5jb20vc2Nh
    MWIuY3JsMCAGA1UdIAQZMBcwCwYJYIZIAYb9bAECMAgGBmeBDAECATB1BggrBgEF
    BQcBAQRpMGcwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnNjYTFiLmFtYXpvbnRy
    dXN0LmNvbTA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5zY2ExYi5hbWF6b250cnVz
    dC5jb20vc2NhMWIuY3J0MAwGA1UdEwEB/wQCMAAwggEEBgorBgEEAdZ5AgQCBIH1
    BIHyAPAAdgC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAAAWynPFdl
    AAAEAwBHMEUCIDmsmeFBC6oF4gYIjdkvUFYI3gCWb7F0zn318Je3HrHqAiEAv7UH
    aD4CtSZhCcrewbZ69W5gE1D/L8GUGXPzaGHRfTwAdgCHdb/nWXz4jEOZX73zbv9W
    jUdWNv9KtWDBtOr/XqCDDwAAAWynPFeYAAAEAwBHMEUCIEIhVFj9aq6fpihaBI84
    geykNXAf/WaOdYUkmOni3k8IAiEApCUwrn9AGtBqr/Nw5a7yxArueju0CLlFKHq9
    XHnro+swDQYJKoZIhvcNAQELBQADggEBAAG7nSk+LLXZVnD3yNdQIz3qnsfIUvBO
    W8cRJYWUXNM5NO/pPJlNXtSS0azdPTtnimZ3AUIXHQEoaYaawrBy7GIDpRDV7Wg/
    juopGN6AFApzG+2KvmV5vNQ2xM54frcBsJ2hm1gE8VEeZurs6iMe0q/D31FrJA1X
    hCveZ53tcixXs3XeyG4fGLX+jdvtCIf8lq+/4FBC1i2diqtUjaCaHEisD58GxuCZ
    T6JcVKNE3YwrsO7jfdcO6XbMtjqGFDVjWNK3vCHjovj7Z+SfOAqlW2oCDCra4c3M
    uSzRVJ1fYpcOmYS8Aaln/GwkqKiZbqirzh+w8VNm9Eihhd8m3RPeJn0=
    -----END CERTIFICATE-----

    So it should fit into the space constrains.

  • trace-2020-06-08T15-03-07.318Z.binThanks. I wrongly assumed the default firmware would be sufficient. After flashing the connectivity bridge fw I could now capture a trace which is attached.

  • Great, thank you! I will have a look at it and get back to you. 

    Edti: I forgot to ask, but what modem fw version are you running on your device?

  • The modem is now running thingy91_nrf52_connectivity_bridge_2020-04-29_bc7ade8b and the NRF9160 application is based on SDK-1.3.0-rc1

  • The Thingy:91 populates two microcontrollers, the ARM Cortex M33 based nRF9160 and the ARM Cortex M4 based nRF52840. The Cortex M33 includes two cores, where one is for application and one is used by the modem. 

    To find the current version of the modem FW, one must send the AT command: AT+CGMR.

    Edit: Have you tested the application using SDK-1.2.0?

  • Firmware is

    mfw_nrf9160_1.2.0

    I tried it with SDK v1.2.0, but the behaviour is the same as with v1.3.0-rc1.

    I also made an attempt with wrong credentials. The Cognito server answered with a BAD REQUEST reply (as expected) which was received by the application (383 bytes). I tried also to expand the receive buffer beyond the expected total size of an answer to a correct authentication (3995 bytes expected, buffer size set to 4096), but I still receive zero bytes.

Reply
  • Firmware is

    mfw_nrf9160_1.2.0

    I tried it with SDK v1.2.0, but the behaviour is the same as with v1.3.0-rc1.

    I also made an attempt with wrong credentials. The Cognito server answered with a BAD REQUEST reply (as expected) which was received by the application (383 bytes). I tried also to expand the receive buffer beyond the expected total size of an answer to a correct authentication (3995 bytes expected, buffer size set to 4096), but I still receive zero bytes.

Children
  • I think I have found the root cause of the problem. I have setup an own SSL server and found that the modem will close the connection and recv returns 0 bytes, if a block of data exceeds 2315 bytes (plaintext). The size limit may depend rather on the size of the actual transmitted data, so permitted length of plaintext may depend on selected cipher suite (in my case it was ECDH-RSA-AES256-SHA). The responses of AWS Cognito are clearly beyond this limit (3995 bytes of plaintext), so I think we will have to abandon AWS Cognito (I assume that the limit is due to the modem's hardware)

  • Christian A. said:
    I assume that the limit is due to the modem's hardware

    Yes, it looks this is the issue I mentioned in my first response: 

    Øyvind said:
    The reason for this is that the nRF9160 only has 2k of RAM for certificates,

      

Related