1. 10 Jul, 2019 1 commit
  2. 09 Jul, 2019 1 commit
  3. 24 May, 2019 1 commit
  4. 27 Feb, 2019 1 commit
  5. 26 Feb, 2019 1 commit
  6. 07 Feb, 2019 1 commit
  7. 20 Nov, 2018 1 commit
  8. 06 Nov, 2018 1 commit
  9. 05 Nov, 2018 1 commit
  10. 11 Jul, 2018 1 commit
  11. 14 Jun, 2018 1 commit
    • Oleksandr Andrieiev's avatar
      [CR2390] Identity spoofing/privelege escalation · bc8c9fdc
      Oleksandr Andrieiev authored
      For secure connections that use certificates the SubjectUUID
      is retrieved from leaf certificate's CN. However, there is
      no binding mechanism between Root CA and Device Id that it
      can generate certificates for. Root CAs can issue certificates
      with arbitrary UUIDs, which can be used to impersonate another
      Device.
      
      The fix adds callback to the certificate chain validation
      function. This callback collects single-linked list of all
      UUIDs associated with the certificate in cred entries.
      When leaf certificate is reached, UUID of Device is retrieved
      and matched against static list. If no matching UUID is
      found, connection should be rejected.
      
      Bug: https://jira.iotivity.org/browse/IOT-3087
      Change-Id: I20333c980226dc6a0c257dc36aab1502202993d9
      Signed-off-by: Oleksandr Andrieiev's avatarOleksandr Andrieiev <o.andrieiev@samsung.com>
      bc8c9fdc
  12. 04 Apr, 2018 1 commit
  13. 27 Mar, 2018 1 commit
  14. 02 Mar, 2018 1 commit
  15. 24 Jan, 2018 1 commit
  16. 15 Nov, 2017 1 commit
  17. 14 Nov, 2017 1 commit
  18. 16 Oct, 2017 1 commit
  19. 13 Oct, 2017 1 commit
  20. 14 Sep, 2017 1 commit
    • saurabh.s9's avatar
      Security error notification engine · ad1f7db6
      saurabh.s9 authored
      Purpose:
      Errors happens during OCDoResource calls should be returned to app layer
      
      Previously, session errors (handshake failed) didn't returned properly to app layer
      and this cause side effects (CA retransmission works in cases when it should not)
      
      Current state:
      1. Source code builds ok
      2. Secure stack samples (UDP/TCP) works well (both positive/negative cases)
      3. Provisioning (OTM, 20th menu item) works well for following:
         a. justworks    positive UDP/TCP, negative UDP case
         b. mfg          positive UDP/TCP, negative UDP case
         c. mv_justworks positive UDP/TCP, negative UDP case
         d. randompin    positive UDP/TCP, negative UDP case
      4. OTM in provisioning via TCP - negative case - should work properly after fix IOT-2454
      
      How to test:
      1. Positive case - just test samples (f.e secure stack samples) & provisioning with all servers
      2. Negative case - add following code which artificially breaks handshake (to ca_adapter_net_ssl.c)
         if (peer->ssl.state == MBEDTLS_SSL_CERTIFICATE_REQUEST)
         {
             ret = MBEDTLS_SSL_ALERT_MSG_INTERNAL_ERROR;
         }
         And again test all samples and provisioning with all servers.
         As result - you should see an error returned to app immidiately (without timeouts, etc)
         and there should be no CA retransmission attempts (UDP case)
      
      Change-Id: Ia1fe1c7c58f9e40040a0be5e7e83abbc66f80bfe
      Signed-off-by: default avatarAndrii Shtompel <a.shtompel@samsung.com>
      Signed-off-by: default avatarsaurabh.s9 <saurabh.s9@samsung.com>
      ad1f7db6
  21. 14 Aug, 2017 1 commit
  22. 11 Aug, 2017 1 commit
  23. 02 Aug, 2017 1 commit
  24. 27 Jun, 2017 1 commit
  25. 08 Jun, 2017 2 commits
  26. 26 May, 2017 1 commit
  27. 22 May, 2017 1 commit
  28. 20 May, 2017 1 commit
  29. 19 May, 2017 1 commit
  30. 18 May, 2017 1 commit
  31. 04 May, 2017 1 commit
  32. 02 May, 2017 1 commit
  33. 26 Apr, 2017 1 commit
  34. 20 Apr, 2017 1 commit
  35. 19 Apr, 2017 1 commit
  36. 17 Apr, 2017 1 commit
  37. 14 Apr, 2017 1 commit
  38. 12 Apr, 2017 2 commits