libsecurity-go

Overview:

The goals of libsecurity are:

Secure "things" that connect to the internet by providing a set of security libraries/services that fulfill the following requirements:

  1. Complete (from a security point of view)
  2. Can be easily integrated with existing IoTs' software.
  3. Optimized for the IoTs' run time environment

Out of scope

  • Denial of service - this mainly refers to applicative implementation related weaknesses (like a poor hash function) which are beyond our reach
  • Physical attacks

Language

Provided Libraries:

  • Initialization services including a utility that generates an initial secureStorage file to be used later by all other components
  • Token services for allowing transfer of users' information between client and server using secure JSON Web Token (JWT) cookies.
  • Account Management services: User privileges and password management
  • Secure storage services: Persistency mechanism that uses Encryption (AES) of key-value pairs within a signed file
  • Entity management services to handle 3 types of entities: User, Group and Resource.
  • Password services: encryption, salting, reset, time expiration, Throttling mechanism
  • OATH services: OCRA as defined by RFC 6287
  • Authentication services as defined by OpenID connect
  • Authorization services as defined by OAUTH 2.0
  • Access Control List (ACL) services when access rights may be defined for resource entity. The implementation should allow flexible types of access to resources (not limited to READ/WRITE/EXECUTE).
  • One Time Password (OTP) services as defined by RFCs 4226 (HOTP), 6238 (TOTP)

Higher layers:

  • RESTful layer: most of the above libraries have a RESTful layer
  • Examples:
    1. Each of the above libraries have usage examples
    2. All the above libraries are combined into libsecurity-go RESTful GUI (each library could be shown/hidden using the tool configuration file)

Installation

Prerequisites

  • Installed Go environment with $GOPATH properly set.

Quick Start

  • Get libsecurity-go and its dependencies: go get github.com/ibm-security-innovation/libsecurity-go/...
  • Running a RESTful GUI example:
    • When entering for the first time, the following steps should be executed:
    1. Generate an RSA file (you can generate it also when generating the basic secure storage, see item 3) by running:
    • ssh-keygen (This will result with the following prompts filled with the user chosen values)
      • Generating public/private rsa key pair.
      • Enter file in which to save the key (~/.ssh/id_rsa): ./dist/test.rsa
      • Enter passphrase (empty for no passphrase):
      • Enter same passphrase again:
      • Your identification has been saved in ./dist/test.rsa
      • Your public key has been saved in ./dist/test.rsa.pub
    1. Create a secureKey file in the ./dist directory. The secureKey file should contain a strong password to be used for encryption of the setup storage file. It is recommended that the password will be based on a random value which is at least 16 bytes long. Note that some additional manipulation will be done for further strengthening the initial password before it is used.
    2. Generate a minimal secure storage (a file that contains just the root user with its privilege and password) and RSA files by executing the following steps:
      • cd setup
      • go run setup_storage_.go -storage-file="./dist/data.txt" -password="your new compliant password here" -secure-key="./dist/secureKey" -generate-rsa=true
      • cd .. Note: if you generated the RSA files, copy them to the dist directory (the generated RSA files are: key.private and key.public)
  • The following should be done any time the RESTful API browser is used:
    • Running the RESTful server
      • change directory to the restful/libsecurity directory
      • go run libsecurity.go
      • -config-file (default "./config.json"): Configuration information file
      • -host (default "127.0.0.1:5443"): Listening host
      • -protocol (default "https"): Using protocol: http ot https
      • -rsa-private (default "./dist/key.private"): RSA private key file path
      • -secure-key (default "./dist/secureKey"): password to encrypt the secure storage
      • -server-cert (default "./dist/server.crt"): SSL server certificate file path for https
      • -server-key (default "./dist/server.key"): SSL server key file path for https
      • -storage-file (default "./dist/data.txt"): persistence storage file
    • In the browser address bar type: https://ip:port/forewind/doc (or http://ip:port/forewind/doc) (The default is: https://127.0.0.1:5443/forewind/doc)
      • click on the /forewind/app/v1/accounts-manager
      • click on the /forewind/app/v1/account-manager/user link in order to authenticate the user
      • After filling the user name and password, click on the Try it out button.
        • If the account information is correct the "Response body" should contain the line "Match" : true.
      • Click on the directory link in order to Change/Update/Save the relevant data using the RESTful API

License

(c) Copyright IBM Corp. 2010, 2015 This project is licensed under the Apache License 2.0. See the LICENSE file for more info.

libsecurity-go architecture and high level design document

Overview:

The purpose of libsecurity-go is to provide an efficient solution for securing Internet Of Things end devices and gateways. This solution does not require any deep understanding of security and thus relieves IoT developers from the need to learn and understand the different aspects of security (e.g. how to create and maintain secure-storage, when to use One Time Password etc.).

Libsecurity-go implementations targeted to Linux capable IoT platforms (e.g. ARM Cortex A). This implementation includes two additional layers: a RESTful layer and an Application layers.

__________ ___________ Architecture Layers ____________ _______________________________
Application Layer
Rrestful API
Account Management + Meta Data
Access Control List Password (with salt) One Time Password OAuth OCRA
Entity Manager
Secure Storage
Encryption

Architecture and High level design:

The following diagram details the layers of libsecurity :

  • The encryption layer is the lowest one (where either Go encryption or NaCl encryption library are used).
  • The second layer, Secure Storage, implements secure storage for persistency. The secure storage is based on encrypted key value pairs stored in signed files to guarantee that the data is not altered or corrupted (more details will be presented later)
  • The next layers are designed as entity centric, where entities must have a name and may have a list of associated properties and a list of members (see more details and example below)

Possible associated properties:

  • Account Management: the entity's privilege (Super user, Admin or User), password related information and handling methods including current password, old passwords list, salt, whether it is a 'one time password' (after password reset), and password expiration time.
  • Password handling (for cases when password mechanism other than the Account management is required). This may include: current password, old passwords list, salt, whether it is a 'one time password' (after password reset), password expiration time, whether the password is locked and more.
  • Access control List (ACL): Permissions associated with the resource entity. Permissions are defined as a string to provide flexibility (in contrast with the old Read/Write/Execute model). The string may have any legal string value (e.g. "Can take", "can play")
    • Note: We chose to implement only a positive mechanism - listing what is allowed. We believe that this is more intuitive and easy to manage compared with a combination of positive assertions with negative ones. More details and examples below

Library structure:

  • Each package includes the code, documentation and a usage example
  • Linux capable systems:
    • RESTful API layer: Each of the components has its own RESTful layer providing interface with external calls (Built GUI interface to the RESTful API using Swagger) Application Layer: A set of “glue components” to ease the use of the security tool (e.g. addition of an ACL permission description)

Major Data and Property Structures:

Secure Storage

- Allows maintaining data persistently and securely. The implementation of the secure storage is based on encrypted key value pairs stored in signed files to guarantee that the data is not altered or corrupted.
- Both the key and the value are encrypted when added to the storage using an Advanced Encryption Standard (AES) algorithm.
- Each time a new secure storage is generated, a secret supplied by the user accompanies it and is used in all HMAC and AES calculations related to that storage .

In order to make it difficult for a third party to decipher or use the stored data we ensure that multiple independent encryptions of the same data (e.g. a block with the same piece of plain text) with the same key have different results. This is achieved by implementing the Cipher Block Chaining (CBC) mode. - In order to implement a time efficient secure storage with keys (i.e. identify keys that are already stored without decrypting the entire storage, and when such a key is identified replacing its value) a two step mechanism is used. The first time a key is introduced, a new IV is drawn, the key is 'HMAC'ed with the secret and is stored with the IV as the value (1st step). Than the original key is encrypted with the drawn IV and stored again, this time with the (encrypted with its own random IV) value (2nd step). The next time that same key is stored, the algorithm, identifies that it already exists in the storage, pulls out the random IV (stored in the 1st step), finds the 2nd step storage of that key and replaces its value with the new (encrypted) one. - In order to guarantee that the data is not altered or corrupted the storage is signed using HMAC. The signature is added to the secure storage, when the storage is loaded, HMAC is calculated and compared with the stored signature to verify that the file is genuine.

  • Entity structure:

    • There are three types of entities: User, Group and resource
      • Users have a name and a list of properties
      • Groups have a name, list of members associated with it (each member is a name of an existing entity) and a list of properties
      • Resources have a name and a list of properties
      • There is a special group entity, that is not defined explicitly, with the name "All". This entity is used in the ACL when the resource has permission properties that applies to all the entities in the system
  • Properties:

    • ACL property structure:

      • An ACL has a list of entries. Each ACL entry consists of the following fields:

        • An entry name (obligatory, must be the name of an entity from the entity list)
        • List of permissions (optional)
      • Example:

        • Consider the following entity list:
          • Name: User1
          • Name: User2
          • Name: User3
          • Name: IBM, members: User2, User3
          • Name: All (reserved token)
          • Name: Disk, properties: ACL:
          • ACL →
            • Name: User1, properties: “can write”, “can take”
            • Name: IBM, properties: “can read”
            • Name: All, Properties: “can execute”
        • In this example:
        1. The user-entity named User1 has the following permissions with relation to the resource-entity Disk: “can write”, “can take” and “can execute” (via All)
        2. The group-entity named IBM has the following permissions with relation to the resource-entity Disk: “can read” and “can execute” (via All)
        3. The user-entity named User2 has the following permissions with relation to the resource-entity Disk: “can read” (via IBM) and “can execute” (via All)
        • Note: if User1 is removed from the Entity list and then re added, the only permission it will initially have is “execute” (via All). This is because a removed entity cannot be re-added, but a new entity with its name can be created. In this case, the new Entity User1 may be of a different user than the one that originally received the permissions.
    • The OTP property:

      • According to Wikipedia: A One Time Password (OTP) is a password that is valid for only one login session or transaction (and may be limited for a specific time period). The most important advantage that is addressed by OTPs is that, in contrast to static passwords, they are not vulnerable to replay attacks. A second major advantage is that a user who uses the same (or similar) password for multiple systems, is not made vulnerable on all of them, if the password for one of these is gained by an attacker. Libsecurity implements the 2 possible OTP implementations: A time based one time password algorithm (TOTP) and HMAC-based one time password algorithm (HOTP). Our OTP implementation is based on RFC 2289 for OTP in general, RFC 4226 for HOTP, and RFC 6238 for TOTP.
      • The OTP implementation has three layers:
        • The base layer includes the secret, the digest (e.g. SHA256, SHA1) and the number of digits in the result.
        • The second layer is the counting mechanism which is time based for TOTP and counter based for HOTP.
        • The topmost layer includes the policy of handing unsuccessful authentication attempts. This includes blocking and throttling. The blocking mechanism allows blocking users for a given duration (or until a manual unblock) after they pass a threshold which a limit for the number of allowed consecutive unsuccessful authentication attempts. The throttling mechanism controls the delay between the authentication request and the response. This delay is increased as the number of consecutive unsuccessful attempts grows to avoid brute force password attacks. This layer also includes a time window for avoiding clock drifting errors when TOTPs are used.
    • The OCRA property:

      • According to Wikipedia: Challenge–response authentication: is a family of protocols in which one party presents a question ("challenge") and another party must provide a valid answer ("response") to be authenticated. It may be used for mutual authentication e.g. when a server needs to install a new version on a client. In the case of the example, the client has to verify that the server is the one it claims it is (otherwise a malicious version may be downloaded) and the server has to verify that it sends the new version to the right client.


libsecurity-go

概述:

libsecurity的目标是:

通过提供满足以下要求的一组安全库/服务来保护连接到互联网的事物:

  1. Complete (from a security point of view)
  2. Can be easily integrated with existing IoTs' software.
  3. Optimized for the IoTs' run time environment

超出范围

  • 拒绝服务 - 这主要是指应用实现相关的弱点(比如一个糟糕的散列函数),这是我们无法达到的
  • 物理攻击

语言

提供的库:

  • 初始化服务,包括生成一个初始secureStorage文件的实用程序,以便以后由所有其他组件使用
  • 允许使用安全的JSON Web令牌(JWT)cookie在客户端和服务器之间传输用户信息的令牌服务。
  • 帐户管理服务:用户权限和密码管理
  • 安全存储服务:在签名文件中使用加密(AES)密钥值对的持久性机制
  • 实体管理服务可以处理3种类型的实体:用户,组和资源。
  • 密码服务:加密,盐化,重置,时间到期,限流机制
  • OATH服务:由RFC 6287定义的OCRA
  • OpenID连接定义的认证服务
  • 由OAUTH 2.0定义的授权服务
  • 访问控制列表(ACL)服务,可以为资源实体定义访问权限。实施应允许灵活的资源访问(不限于READ / WRITE / EXECUTE)。
  • 由RFC 4226(HOTP),6238(TOTP)定义的一次性密码(OTP)服务

较高层:

  • RESTful图层:大部分上述图书馆都有一个RESTful图层
  • 示例:
    1. 上述每个库都有使用示例
    2. 所有上述库都组合到libsecurity-go RESTful GUI中(每个库都可以使用工具配置文件显示/隐藏)

安装

前提条件

  • 正确设置 $ GOPATH 的安装Go环境。

快速入门

    获取libsecurity-go及其依赖项: go get github.com/ibm-security-innovation/libsecurity-go/…
  • 运行RESTful GUI示例:
    • 首次输入时,应执行以下步骤:
      生成RSA文件(您也可以在生成基本安全存储时生成它,参见第3项),方法是运行:
    • ssh-keygen (这将导致填充用户选择的值的以下提示)
      • 生成公共/私人rsa密钥对
      • 输入要保存密钥的文件(〜/ .ssh / id_rsa):./dist/test.rsa
      • 输入密码(无密码为空):
      • 再次输入相同的密码:
      • 您的身份已保存在./dist/test.rsa
      • 您的公钥已保存在./dist/test.rsa.pub
    1. 在./dist目录中创建一个secureKey文件。 secureKey文件应包含用于加密安装存储文件的强密码。建议密码将基于长度至少为16个字节的随机值。请注意,在使用初始密码之前,将进行一些额外的操作来进一步加强初始密码。
    2. 通过执行以下步骤,生成最小安全存储(仅包含具有其特权和密码的root用户的文件)和RSA文件:
      • cd setup
      • go run setupstorage.go -storage-file =./ dist / data.txt-password =您的新兼容性 密码在这里-secure-key =./ dist / secureKey-generate-rsa = true
      • cd .. 注意:如果您生成了RSA文件,请将其复制到dist目录(生成的RSA文件为:key.private和key.public)
  • 在使用RESTful API浏览器的任何时候都应该执行以下操作:
    • 运行RESTful服务器
      • 将目录更改为restful / libsecurity目录
      • go运行libsecurity.go
      • -config-file(默认./config.json):配置信息文件
      • -host(默认为127.0.0.1:5443):听主机
      • -protocol(默认https):使用协议:http ot https
      • -rsa-private(默认./dist/key.private):RSA私钥文件路径
      • -secure-key(默认./dist/secureKey):加密安全存储的密码
      • -server-cert(默认./dist/server.crt):https的SSL服务器证书文件路径
      • -server-key(默认./dist/server.key):https的SSL服务器密钥文件路径
      • -storage-file(默认./dist/data.txt):持久存储文件
    • 在浏览器地址栏中输入: https:// ip:port / forewind / doc (或 http:// ip:port / forewind / doc )(默认值为: https://127.0.0.1:5443/forewind/doc
      • 点击 / forewind / app / v1 / accounts-manager
      • 点击 / forewind / app / v1 / account-manager / user 链接,以验证用户
      • 填写用户名和密码后,点击试试看按钮。
        • 如果帐户信息正确,响应体应包含Match:true
      • 点击目录链接,使用RESTful API
      • 更改/更新/保存相关数据

许可证

(c)版权所有IBM Corp. 2010,2015 该项目是根据Apache许可证2.0授权的。有关更多信息,请参阅LICENSE文件。

libsecurity-go architecture and high level design document

概述:

libsecurity-go的目的是为物联网终端设备和网关提供有效的解决方案。该解决方案不需要对安全性的深入了解,从而减轻了IoT开发人员了解和了解安全性的不同方面(例如如何创建和维护安全存储,何时使用一次性密码等)。 p> 针对支持Linux的IoT平台(例如ARM Cortex A)的Libsecurity-go实现。此实现包括两个附加层:RESTful层和应用层。

_______ _____ Architecture Layers ______ ____________________________
Application Layer
Rrestful API
Account Management + Meta Data
Access Control List Password (with salt) One Time Password OAuth OCRA
Entity Manager
Secure Storage
Encryption

架构和高级设计:

下图详细说明了libsecurity的层次:

  • 加密层是最低的(使用Go加密或NaCl加密库)。
  • 第二层Secure Storage实现了持久性的安全存储。安全存储基于存储在签名文件中的加密密钥值对,以保证数据不被更改或损坏(稍后将会提供更多细节)
  • 下一层被设计为以实体为中心,其中实体必须具有一个名称,并且可以具有关联的属性列表和成员列表(参见下面的更多细节和示例)

可能的关联属性:

  • 帐户管理:实体的特权(超级用户,管理员或用户),密码相关信息和处理方式,包括当前密码,旧密码列表,盐,是否为一次性密码(密码重置后),以及密码到期时间。
  • 密码处理(对于需要密码机制而不是客户管理的情况)。这可能包括:当前密码,旧密码列表,盐,是否是一次性密码(密码重置后),密码到期时间,密码是否被锁定等。
  • 访问控制列表(ACL):与资源实体相关联的权限。权限被定义为一个字符串,以提供灵活性(与旧的读/写/执行模型相反)。字符串可能具有任何合法的字符串值(例如可以采取,可以播放)
    • 注意:我们选择仅实施一个积极的机制 - 列出允许的内容。我们认为,与积极主张与负面主张的组合相比,这更直观和易于管理。
    • 下面的更多细节和例子

库结构:

  • 每个包都包含代码,文档和使用示例
  • 支持Linux的系统:
      RESTful API层:每个组件都有自己的RESTful层,提供外部调用接口(使用Swagger构建RESTful API的GUI界面) 应用程序层:一组粘合组件,以便于安全工具的使用(例如添加ACL权限描述)

主要数据和属性结构:

Secure Storage

- Allows maintaining data persistently and securely. The implementation of the secure storage is based on encrypted key value pairs stored in signed files to guarantee that the data is not altered or corrupted.
- Both the key and the value are encrypted when added to the storage using an Advanced Encryption Standard (AES) algorithm.
- Each time a new secure storage is generated, a secret supplied by the user accompanies it and is used in all HMAC and AES calculations related to that storage .
为了使第三方难以解密或使用存储的数据,我们确保具有相同密钥的相同数据(例如具有相同的纯文本的块)的多个独立加密具有不同的结果。这通过实现密码块链接(CBC)模式来实现。 - 为了实现具有密钥的时间有效的安全存储(即,识别已经存储的密钥而不解密整个存储器,并且当识别出这样的密钥替换其值时)使用两步机制。第一次介绍一个关键字,绘制一个新的IV,关键是HMAC与秘密,并以IV作为值存储(第一步)。用原来的密钥加密,并且再次存储,这次用(自己随机的IV)值加密(第二步)。下一次存储相同的密钥时,算法识别它已经存在于存储器中,拉出随机IV(存储在第一步),找到该密钥的第二级存储,并用新的(加密)一。 - 为了保证数据不被更改或损坏,使用HMAC签名存储。签名被添加到安全存储中,当加载存储时,HMAC被计算并与存储的签名进行比较以验证该文件是否是真实的。

  • 实体结构:

    • 有三种类型的实体:用户,组和资源
      • 用户名称和属性列表
      • 组具有名称,与其关联的成员列表(每个成员是现有实体的名称)和属性列表
      • 资源有一个名称和一个属性列表
      • 有一个特殊的组实体,没有明确定义,名称为全部。当资源具有适用于系统中所有实体的权限属性
      • 时,该实体在ACL中使用
  • 属性:

    • ACL属性结构:

      • ACL具有条目列表。每个ACL条目由以下字段组成:

        • 条目名称(必须是实体列表中的实体的名称)
        • 权限列表(可选)
      • 示例:

        • 考虑以下实体列表:
          • 名称:User1
          • 名称:User2
          • 名称:User3
          • 名称:IBM,成员:User2,User3
          • 名称:全部(保留令牌)
          • 名称:磁盘,属性:ACL:
          • ACL
            • 名称:User1,属性:可以写,可以采取
            • 名称:IBM,属性:可以读
            • 名称:全部,属性:可以执行
        • 在这个例子中:
        1. 名为User1的用户实体具有与资源实体Disk相关的以下权限:可以写入,可以执行和可以执行(通过全部)
        2. 名为IBM的组实体具有与资源实体磁盘相关的以下权限:可以读取和可以执行(通过全部)
        3. 名为User2的用户实体具有与资源实体Disk相关的以下权限:可以读取(通过IBM)和可以执行(通过全部)
        • 注意:如果User1从实体列表中删除,然后重新添加,则它最初将具有的唯一权限是执行(通过全部)。这是因为删除的实体无法重新添加,而是可以创建一个名称为新的实体。在这种情况下,新的Entity User1可能是与最初收到权限的用户不同的用户。
    • OTP属性:

      • 根据维基百科:一次性密码(OTP)是仅对一个登录会话或事务有效的密码(可能在特定时间段内被限制)。 OTP解决的最重要的优点是,与静态密码相比,它们不容易受到重放攻击。第二个主要的优点是,对于多个系统使用相同(或类似的)密码的用户,如果其中一个的密码由攻击者获得,则不会对所有用户造成易受攻击。 Libsecurity实现了两种可能的OTP实现:基于时间的一次密码算法(TOTP)和基于HMAC的一次密码算法(HOTP)。我们的OTP实现基于用于OTP的RFC 2289,HOTP的RFC 4226和TOTP的RFC 6238。
      • OTP实现有三个层次:
        • 基本层包括秘密,摘要(例如SHA256,SHA1)和结果中的位数。
        • 第二层是基于TOTP的计时机制,基于HOTP的计数器。
        • 最上层包括递交不成功的身份验证尝试的策略。这包括阻塞和调节。阻塞机制允许在通过允许的连续不成功身份验证尝试次数限制的阈值之后,阻止用户给定持续时间(或直到手动解除阻塞)。节流机制控制认证请求和响应之间的延迟。随着连续不成功的尝试次数增加以避免暴力密码攻击,这种延迟增加。该层还包括一个时间窗口,用于在使用TOTP时避免时钟漂移错误。
    • OCRA属性:

      • 根据维基百科:挑战响应认证:是一个协议族,其中一方提出一个问题(挑战),另一方必须提供有效答案(响应)进行身份验证。它可以用于相互认证,例如当服务器需要在客户端上安装新版本时。在该示例的情况下,客户端必须验证服务器是否是它所声称的服务器(否则可能会下载恶意版本),并且服务器必须验证它是否将新版本发送到正确的客户端。 li>




相关问题推荐