Hyperledger Technical Steering Committee (TSC) accepts new cryptographic library

Hyperledger, the open source collaborative effort created to advance cross-industry blockchain technologies has announced that Hyperledger Ursa is the latest project to be accepted by the Hyperledger Technical Steering Committee (TSC). Ursa is a modular, flexible cryptography library that is intended for (but not limited to) use by other projects in Hyperledger.

Ursa aims to include things like a comprehensive library of modular signatures and symmetric-key primitives built on top of existing implementations, so blockchain developers can choose and modify their cryptographic schemes with a simple configuration file change. Ursa will also have implementations of newer, fancier cryptography, including things like pairing-based signatures, threshold signatures, and aggregate signatures, and also zero-knowledge primitives like SNARKs.

Available on GitHub, Ursa will be written mostly in Rust, but will have interfaces in all of the different languages commonly used throughout Hyperledger.

Why Ursa?

As Hyperledger has matured, the individual projects within Hyperledger have started to find a need for sophisticated cryptographic implementations. Rather than have each project implement its own cryptographic protocols, it is much better to collaborate on a shared library. There are many reasons to do this, including the following:

  1. Avoiding duplication: Crypto implementations are notoriously difficult to get correct (particularly when side channels are taken into account) and often require a lot of work in order to achieve a high level of security. The library allows projects to share crypto implementations, avoiding unnecessary duplication and extra work.
  2. Security: Having most (or all) of the crypto code in a single location substantially simplifies the security analysis of the crypto portion of Hyperledger. In addition, the lack of duplication means maintenance is easier (and thus, hopefully, security bugs are less numerous). The presence of easy to use, secure crypto implementations might also make it less likely for less experienced people to create less secure implementations.
  3. Expert Review: In addition, the ability to enforce expert review of all cryptographic code should increase security as well. Having all cryptographic code in a single location makes it easier to concentrate all of the cryptographic expertise in the project and ensures that code will be well reviewed, thus decreasing the likelihood of dangerous security bugs.
  4. Cross-platform interoperability: If two projects use the same crypto libraries, it simplifies (substantially in some cases) cross-platform interoperability, since cryptographic verification involves the same protocols on both sides.
  5. Modularity: This could be the first common component/module and a step towards modular DLT platforms, which share common components. A successful crypto library encourages and pushes forward more modular activities.
  6. New Projects: It is easier for new projects to get off the ground if they have easy access to well-implemented, modular cryptographic abstractions.
Features and Plans

Currently, Ursa has two distinct modules: a library for modular, flexible, and standardized basic cryptographic algorithms, and a library for more exotic cryptography, including so-called “smart” signatures and zero knowledge primitives called zmix.

The first library is the “base crypto” library. Right now Hyperledger is focused on its shared modular signature library, but plans to extend this to allow easy modularization of all commonly used cryptographic primitives in Minicrypt. This (work in progress) has the implementation of several different signature schemes with a common API, allowing for blockchain builders to change signature schemes almost on-the-fly—or to use and support multiple signature schemes easily. Exact implementations and APIs have not been finalized, but Hyperledger notes that they are in progress.

There aren’t raw crypto implementations in this library, things here are stable and generally standardized, says Hyperledger — but wrappers for code come from existing libraries and also code generated by commonly used cryptography libraries such as the Apache Milagro Crypto Library (AMCL). The novelty here is the modularization and API, which enables blockchain platforms to easily use a wide variety of changeable cryptographic algorithms without having to understand or interact with the underlying mathematics.

In the future, Hyperledger expects other wrappings and modular code to go in this library. For instance, Hyperledger Indy makes use of aggregate signatures, a feature which the other platforms would also like available to them. There are also a variety of hash algorithms which provide different performance characteristics or support different signature schemes. Selecting vetted implementations and providing a common interface helps the Hyperledger community manage a growing crypto feature set in a responsible manner.

Our second initial subproject is zmix, which offers a generic way to create zero-knowledge proofs that prove statements about multiple cryptographic building blocks, including signatures, commitments, and verifiable encryption. The goal of zmix is to provide a single flexible and secure implementation to construct such zero-knowledge proofs. Zmix consists of C-callable code but there are also convenience wrappers for various programming languages.

Who Is Involved in Ursa?

On the more practical side, Ursa currently includes developers who work on the security aspects of Hyperledger Indy, Sawtooth, and Fabric. In addition, the Ursa project includes several cryptographers with an academic background in theoretical cryptography to ensure that all cryptographic algorithms meet the desired levels of security.

The goal of creating Ursa is to combine the efforts of all the security and cryptography experts in the Hyperledger community and move all of the projects forward.

Related:

Cisco Meeting Server Information Disclosure Vulnerability

A vulnerability in Cisco Meeting Server could allow an unauthenticated, remote attacker to gain access to sensitive information.

The vulnerability is due to improper protections on data that is returned from user meeting requests when the Guest access via ID and passcode option is set to Legacy mode. An attacker could exploit this vulnerability by sending meeting requests to an affected system. A successful exploit could allow the attacker to determine the values of meeting room unique identifiers, possibly allowing the attacker to conduct further exploits.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181107-meeting-server

Security Impact Rating: Medium

CVE: CVE-2018-15446

Related:

Permissions required on Certificate Templates Used By FAS Servers Getting Errors “FAS _Cert Pending Request_Citrix RegistrationAuthority_ManualAuthorization”

Permissions required on Certificate Authority Server Certificate Templates recommended by Citrix:

1. Remove Domain Computers (for security reasons) from Citrix_RegistrationAuthority_ManualAuthorization,Citrix_RegistrationAuthority & Citrix_SmartLogon templates on the Certificate Authority used by FAS Servers.

2. Under each template add FAS servers explicitly and give Read, Enroll & AutoEnroll permissions.

3. Apart from the above permissions need additional permissions in the templates.

Authenticated Users: Read Permission

System: Full Permission

4. Enterprise AdminFull Permission can also be added if necessary. (Not Mandatory)

Note :FAS issue certificates to only intended users.

Related:

  • No Related Posts

Cisco Wireless LAN Controller Software Privilege Escalation Vulnerability

A vulnerability in the authentication and authorization checking mechanisms of Cisco Wireless LAN Controller (WLC) Software could allow an authenticated, adjacent attacker to gain network access to a Cisco TrustSec domain. Under normal circumstances, this access should be prohibited.

The vulnerability is due to the dynamic assignment of Security Group Tags (SGTs) during a wireless roam from one Service Set Identifier (SSID) to another within the Cisco TrustSec domain. An attacker could exploit this vulnerability by attempting to acquire an SGT from other SSIDs within the domain. Successful exploitation could allow the attacker to gain privileged network access that should be prohibited under normal circumstances.

There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181017-wlan-escalation

Security Impact Rating: Medium

CVE: CVE-2018-15395

Related:

Cisco Wireless LAN Controller Software Directory Traversal Vulnerability

A vulnerability in the web-based interface of Cisco Wireless LAN Controller Software could allow an authenticated, remote attacker to view sensitive information.

The issue is due to improper sanitization of user-supplied input in HTTP request parameters that describe filenames and pathnames. An attacker could exploit this vulnerability by using directory traversal techniques to submit a path to a desired file location. A successful exploit could allow the attacker to view system files on the targeted device, which may contain sensitive information.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181017-wlc-traversal

Security Impact Rating: Medium

CVE: CVE-2018-0420

Related:

Having problems with the following certificate confirmation, you get the following message: “The servirdor certificate is not in your trusted store.”

I need a solution

I am having a problem with the following certificate confirmation that looks like it is being stored on a server that is no longer acting as an effective manager device in my enterprise. How do I proceed in a way that this confirmation is no longer necessary to confirm, knowing that the same certification confirmation is being stored in a server that is no longer active in the company, understanding the risks they can generate in case that same certificate is not being stored in my Antivirus service unit?

0

Related:

Cisco HyperFlex World-Readable Sensitive Information Vulnerability

A vulnerability in the installation process of Cisco HyperFlex Software could allow an authenticated, local attacker to read sensitive information.

The vulnerability is due to insufficient cleanup of installation files. An attacker could exploit this vulnerability by accessing the residual installation files on an affected system. A successful exploit could allow the attacker to collect sensitive information regarding the configuration of the system.

There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181003-hyperflex-info

Security Impact Rating: Medium

CVE: CVE-2018-15407

Related: