1. 16 Apr, 2020 1 commit
  2. 15 Apr, 2020 1 commit
  3. 10 Oct, 2019 1 commit
    • George Nash's avatar
      Rename include files with `common` suffix · a004bb8b
      George Nash authored
      The reason oc_acl_common.h and oc_cred_common.h have the
      suffix common is because the code contained in the headers
      is common to both the public and private APIs. Using the
      suffix common is meaningless to the user of the iotivity-lite
      framework.  What are the headers "common" to from the user
      For this reason the following files have been renamed
        include/oc_acl_common.h --> include/oc_acl.h
        include/oc_cred_common.h --> include/oc_cred.h
        security/oc_acl.h --> security/oc_acl_internal.h
        security/oc_cred.h --> security/oc_cred_internal.h
      This removes the confusing "common" suffix while adding
      the "internal" suffix for code that is already considered
      internal to the framework.
      The #include has been changed to reflect the new file name.
      Change-Id: I15df170f1172e3781dcf42e7716700f1bdea629a
      Signed-off-by: George Nash's avatarGeorge Nash <george.nash@intel.com>
  4. 14 Jul, 2019 1 commit
  5. 11 Jul, 2019 1 commit
    • Kishen Maloor's avatar
      oc_pki & oc_cred: updates and fixes · 76fd81e0
      Kishen Maloor authored
      -Install cert chains in PEM instead of DER.
      -Removed special logic for provisioning DER chains. The use of the DER
      format has been deprecated in the OCF Security Specification.
      -Fixed logic for locating a role credential with/without an authority.
      -Fixed oc_sec_clear_creds() to remove all cred entries (including any
      pre-installed PKI chains) upon every DELETE or RESET. PKI chains may
      be reinstalled later from the factory_presets callback.
      -Fixed logic while receiving an identity cert to check for a
      match of public key from the certificate with the device's own
      public key. This would enable the provisioning of cred entries
      with/without the device's own UUID being filled into that entry's
      Previously there was logic that checked for a match of the
      cred entry's "subjectuuid" and the device's own deviceuuid. This
      required OBTs to provision a cred object with the correct "subjectuuid".
      This change has instead made it more flexible for OBTs by removing
      any reliance on "subjectuuid".
      -Fixed add_new_cred() to parse role certificates when provisioned
      to a Client's /oic/sec/cred and extract the roleid for storage
      inside the cred entry.
      Change-Id: I59a1f11272bc546e4d21af37742658f4403d1449
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
  6. 24 Jan, 2019 1 commit
  7. 31 Dec, 2018 1 commit
    • Kishen Maloor's avatar
      oc_roles:support /oic/sec/roles & role assertion · 607319ee
      Kishen Maloor authored
      This change adds support for the /oic/sec/roles resource on Servers
      for role-based access-control using role certificates, as well as Client
      hooks and APIs to assert roles provisioned to it.
      As /oic/sec/roles shares its schema in large part with /oic/sec/cred,
      oc_cred has been updated so its GET/POST/DELETE handlers may also be
      used to service requests to /oic/sec/roles. With an awareness of which
      of the two resources is being currently handled, some logic
      has been added to oc_cred to perform the appropriate actions for each
      resource type. This enables reuse of existing code and flows for parsing
      requests to /oic/sec/cred for /oic/sec/roles, and checking for credid
      uniqueness, while accounting for minor behavioral differences.
      oc_sec_cred_t objects are however recorded separately for the two
      resources and oc_roles stores all roles (in oc_sec_cred_t objects) asserted
      via requests to /oic/sec/roles. Also, the encoding function for the
      /oic/sec/roles response representation is separate from that of /oic/sec/cred.
      oc_roles provides internal APIs for managing role assertions
      on the Server-side and to help assert roles on the Client-side.
      On the Server-side, all roles asserted by various Clients are
      indexed by (D)TLS session in oc_roles. As all asserted roles must be valid
      when they're used for role-based access-control, the Server-side
      stores a parsed role certificate for each role asserted in an
      associated mbedTLS object in memory which may be directly queried for
      a validity check by the access-control flow at the time of handling a
      Client request to a resource. A new void* parameter has been added to
      oc_sec_cred_t to store a handle to this mbedtls_x509_crt object.
      oc_roles automatically frees these mbedtls_x509_crt objects
      for role certificates when the role is freed.
      On the Client-side, oc_roles tracks all roles provisioned to
      the Client in its /oic/sec/cred resource by the OBT/CMS for its use. It
      provides APIs for a Client to list all roles available to it, and for
      asserting a role to a Server via a request to /oic/sec/roles.
      Change-Id: Id25dbc767141da06f65a46fad1a740da2633d15e
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/27802
  8. 14 Dec, 2018 1 commit
  9. 05 Dec, 2018 1 commit
    • Kishen Maloor's avatar
      oc_pki: add APIs to configure manufacturer certs · 408b69ca
      Kishen Maloor authored
      This change adds new and simple public APIs for applications/tools
      to pre-configure a manufacturer certificate chain on an OCF device
      via functions for setting the end-entity manufacturer certificate
      (and its accompanying private key), an intermediate CA certificate
      (if there's one) and the root certificate/trust anchor.
      The APIs accept "char" arrays and may be supplied with PEM
      encoded strings or DER encoded byte arrays alike. The implementation
      internally works out the format, performs parsing using mbedTLS and
      populates cred entries into the /oic/sec/cred resource and persists
      those entries to storage.
      All APIs return the credid of the populated cred entry in
      The APIs also attempt to check for duplicates, i.e. if there already
      exists cred entries with the required credusage containing the
      same certificate, it will simply return the credid of that entry
      and not duplicate it.
      Further adding an intermediate cert needs the user the supply the
      credid of an existing end-entity cert in /oic/sec/cred. The API for
      adding intermediate certs checks for its existence and also verfies
      that the end-entity cert was indeed issued by the intermediate
      cert before adding it to /oic/sec/cred.
      The APIs return -1 for errors.
      Change-Id: Ib57cb6e42d08335e422c8be515b6de0559c53596
      Signed-off-by: Kishen Maloor's avatarKishen Maloor <kishen.maloor@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/27691