• State Verified Answer
  • Locked Locked
  • Replies 10 replies
  • Subscribers 91 subscribers
  • Views 2223 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 285490
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NRF9160 Board for Qr Code Project

Gioele 
I closed the previous discussion by mistake: https://devzone.nordicsemi.com/f/nordic-q-a/83067/nrf9160-board-for-qr-code-project?ReplySortBy=CreatedDate&ReplySortOrder=Ascending

None can read the QR code directly because the QR Code is in a secure anti-tamper location with reliable staff. So we need to make secure the transmission.

How we can see what we are using? We didn't touch anything about the domain of the example so probably we are using the SPM.

These are the logs when we try to execute the uart in non secure domain:

2022-03-08T14:46:31.601Z DEBUG modem << * Booting Zephyr OS build v2.6.99-ncs1-1  *
2022-03-08T14:46:31.604Z DEBUG modem << Flash regionsDomainPermissions
2022-03-08T14:46:31.611Z DEBUG modem << 00 01 0x00000 0x10000 Securerwxl
2022-03-08T14:46:31.612Z DEBUG modem << 02 31 0x10000 0x100000 Non-Securerwxl
2022-03-08T14:46:31.614Z DEBUG modem << Non-secure callable region 0 placed in flash region 1 with size 32.
2022-03-08T14:46:31.616Z DEBUG modem << SRAM regionDomainPermissions
2022-03-08T14:46:31.617Z DEBUG modem << 00 07 0x00000 0x10000 Securerwxl
2022-03-08T14:46:31.619Z DEBUG modem << 08 31 0x10000 0x40000 Non-Securerwxl
2022-03-08T14:46:31.620Z DEBUG modem << PeripheralDomainStatus
2022-03-08T14:46:31.622Z DEBUG modem << 00 NRF_P0               Non-SecureOK
2022-03-08T14:46:31.624Z DEBUG modem << 01 NRF_CLOCK            Non-SecureOK
2022-03-08T14:46:31.625Z DEBUG modem << 02 NRF_RTC0             Non-SecureOK
2022-03-08T14:46:31.626Z DEBUG modem << 03 NRF_RTC1             Non-SecureOK
2022-03-08T14:46:31.628Z DEBUG modem << 04 NRF_NVMC             Non-SecureOK
2022-03-08T14:46:31.629Z DEBUG modem << 05 NRF_UARTE1           Non-SecureOK
2022-03-08T14:46:31.630Z DEBUG modem << 06 NRF_UARTE2           SecureSKIP
2022-03-08T14:46:31.631Z DEBUG modem << 07 NRF_TWIM2            Non-SecureOK
2022-03-08T14:46:31.633Z DEBUG modem << 08 NRF_SPIM3            Non-SecureOK
2022-03-08T14:46:31.634Z DEBUG modem << 09 NRF_TIMER0           Non-SecureOK
2022-03-08T14:46:31.635Z DEBUG modem << 10 NRF_TIMER1           Non-SecureOK
2022-03-08T14:46:31.636Z DEBUG modem << 11 NRF_TIMER2           Non-SecureOK
2022-03-08T14:46:31.637Z DEBUG modem << 12 NRF_SAADC            Non-SecureOK
2022-03-08T14:46:31.639Z DEBUG modem << 13 NRF_PWM0             Non-SecureOK
2022-03-08T14:46:31.640Z DEBUG modem << 14 NRF_PWM1             Non-SecureOK
2022-03-08T14:46:31.641Z DEBUG modem << 15 NRF_PWM2             Non-SecureOK
2022-03-08T14:46:31.667Z DEBUG modem << 16 NRF_PWM3             Non-SecureOK
2022-03-08T14:46:31.670Z DEBUG modem << 17 NRF_WDT              Non-SecureOK
2022-03-08T14:46:31.672Z DEBUG modem << 18 NRF_IPC              Non-SecureOK
2022-03-08T14:46:31.674Z DEBUG modem << 19 NRF_VMC              Non-SecureOK
2022-03-08T14:46:31.677Z DEBUG modem << 20 NRF_FPU              Non-SecureOK
2022-03-08T14:46:31.681Z DEBUG modem << 21 NRF_EGU1             Non-SecureOK
2022-03-08T14:46:31.684Z DEBUG modem << 22 NRF_EGU2             Non-SecureOK
2022-03-08T14:46:31.686Z DEBUG modem << 23 NRF_DPPIC            Non-SecureOK
2022-03-08T14:46:31.688Z DEBUG modem << 24 NRF_REGULATORS       Non-SecureOK
2022-03-08T14:46:31.689Z DEBUG modem << 25 NRF_PDM              Non-SecureOK
2022-03-08T14:46:31.692Z DEBUG modem << 26 NRF_I2S              Non-SecureOK
2022-03-08T14:46:31.694Z DEBUG modem << 27 NRF_GPIOTE1          Non-SecureOK
2022-03-08T14:46:31.695Z DEBUG modem << SPM: NS image at 0x10000
2022-03-08T14:46:31.697Z DEBUG modem << SPM: NS MSP at 0x20018af8
2022-03-08T14:46:31.698Z DEBUG modem << SPM: NS reset vector at 0x16d81
2022-03-08T14:46:31.700Z DEBUG modem << SPM: prepare to jump to Non-Secure image.
2022-03-08T14:46:31.702Z DEBUG modem << * Booting Zephyr OS build v2.6.99-ncs1-1  *


We are reading from the UART using exactly the lpuart of the example online (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.7.1/nrf/samples/peripheral/lpuart/README.html) and we think that the data from the QR code scanner are stored like a string.
Parents
  • 0

    What data is stored in the QR codes?

    How is it formatted? Does it have a fixed length?

    If not, I see from the data sheet of the QR scanner that it can append a suffix for the data, so that you know where the data ends.

    How is your project configured?

    If you based your UART code on the lpuart sample, did you update the name of the config files to reflect that you are now building for "the non-secure board"?

    You also say that you are going to use GPS. I assume you want the position of the QR code?

    That will be difficult if the QR code is indoors, as the GPS signals aren't strong enough to be received indoors.

    Edit: Also, could you make sure CONFIG_LOG=y and CONFIG_RESET_ON_FATAL_ERROR=n is set? That might help us get more logs. Also, you need to make sure that UART0 has not been disabled.

  • 0 in reply to Didrik Rokhaug

    Okay, probably you didn't understand me. Let's restart again.

    This is a university project with some mandatory requests that we must follow.
    We need to realize an application that:
    1)Pick the actual GPS and time and store it in the memory and overwrite the old position with the new position.
    2)Read the QR code and create a JSON where we store in the memory a records queue where each record has the qr code data, the time, the gps (and maybe a public key)
    3)Send all of this with the ECC encryption to a blockchain. For now, we can send it to an API rest with the SIM that we buy(nb-IoT connection)

    And all of this application must be tamper-proof, so
    1)No man in the middle
    2)Nobody should see or modify our code when they take the board
    3)The board must be protected by a pin before the use
    4)The data in JSON must be encrypted (probably we should put this information in a secure portion of the flash memory)
    5)All the application should work in the secure domain
    6)We should implement the concept of Arm Trust zone


    And for now, about the tamper-proof we have nothing. About the request of the application we need to fuse the two applications but for now, we have problems starting the lpuart in no secure domain and cleaning the buffer of the uart after each read. And of course, we didn't send anything for now.

    We need to finish this project as soon as possible.

  • 0 in reply to Gioele
    Gioele said:
    5)All the application should work in the secure domain

    This is not possible, as the modem_lib (which you need for communicating with the modem) only works in the non-secure domain.

    The requirement also doesn't make sense, because running something in the secure domain doesn't magically make anything "safe" or "secure". It is the sepparation between the domains that are important.

    Gioele said:
    4)The data in JSON must be encrypted (probably we should put this information in a secure portion of the flash memory)

    Does the server expect the data to be encrypted? If it doesn't, and you send it encrypted data, it will not understand anything.

    Encryption while the data is in-flight is best done with TLS.

    And storing it in "a secure portion of the flash memory" only makes it impossible for code running in the non-secure domain to access it.

    Gioele said:
    we have problems starting the lpuart in no secure domain and cleaning the buffer of the uart after each read. And of course, we didn't send anything for now.

    The lpuart sample works without issues in the non-secure domain, so there shouldn't be any limitations there.

    Probably, there is something you have configured wrong. But I cannot say that for sure, or say what you have done wrong without seeing how you have configured your application.

    And to be able to comment on how to clean the buffer, I need to see how you are using your buffers and how you read from the UART.

Reply
  • 0 in reply to Gioele
    Gioele said:
    5)All the application should work in the secure domain

    This is not possible, as the modem_lib (which you need for communicating with the modem) only works in the non-secure domain.

    The requirement also doesn't make sense, because running something in the secure domain doesn't magically make anything "safe" or "secure". It is the sepparation between the domains that are important.

    Gioele said:
    4)The data in JSON must be encrypted (probably we should put this information in a secure portion of the flash memory)

    Does the server expect the data to be encrypted? If it doesn't, and you send it encrypted data, it will not understand anything.

    Encryption while the data is in-flight is best done with TLS.

    And storing it in "a secure portion of the flash memory" only makes it impossible for code running in the non-secure domain to access it.

    Gioele said:
    we have problems starting the lpuart in no secure domain and cleaning the buffer of the uart after each read. And of course, we didn't send anything for now.

    The lpuart sample works without issues in the non-secure domain, so there shouldn't be any limitations there.

    Probably, there is something you have configured wrong. But I cannot say that for sure, or say what you have done wrong without seeing how you have configured your application.

    And to be able to comment on how to clean the buffer, I need to see how you are using your buffers and how you read from the UART.

Children
No Data
Related
Terms of service