Various embodiments of the present disclosure are generally directed to the management of data transferred through a computer network by monitoring trust levels of intermediate nodes between a source node and a receiving node.
In some embodiments, trust levels are assigned to each of the nodes in the network. Data are transferred from a source node to a destination node along a selected data path. Trust levels of the intermediate nodes along the data path are monitored and reported to a user associated with the destination node. In some cases, nodes having unacceptable trust levels are avoided as part of the data path. In other cases, paths that include nodes with unacceptably low trust levels result in the received data being subjected to additional levels of verification.
These and other features which characterize various embodiments of the present disclosure can be understood in view of the following detailed discussion and the accompanying drawings.
Various embodiments of the present disclosure are generally directed to establishing and tracking trust levels for various nodes in a computer network as data sets are transferred through the network from a source node to a destination node.
Data security schemes are used to protect data in a computer system against access and tampering by an unauthorized third party. Data security schemes can employ a variety of cryptographic security techniques, such as data encryption and other data security protocols.
Data encryption generally involves the transformation of an input data sequence into an encrypted output data sequence using a selected encryption algorithm. The input data can be referred to as plaintext, the output data can he referred to as ciphertext, and the selected encryption algorithm can be referred to as a. cipher. The cipher may utilize one or more pieces of auxiliary data (keys) to effect the transformation. In this context, plaintext can include data that have been previously encrypted by an upstream encryption process, so encrypted ciphertext can be plaintext for a downstream encryption process.
Data security protocols generally deal with maintaining the security of data within a system, such as by establishing symmetric keys, carrying out secret sharing transactions, establishing and verifying connections, authenticating data, generating digital signatures and keyed message digests, establishing block chain ledgers, issuing challenge values for an authentication process, etc. In some cases, UMACs (hashed message authentication codes) can be generated and transmitted along with a data payload to help ensure that the received data payload from a secure source has not been altered or corrupted in transit.
These and other data security schemes are implemented around a concept often referred to as trust. Generally speaking, trust is a signifier that indicates the extent to which a particular data set can be either accepted for further processing or rejected and discarded. The trust level is a measure of the trustworthiness, or confidence, that can be placed in the data. A trusted relationship exists between nodes if there is sufficient. evidence that communications among the nodes are reliable and trustworthy. As in human relationships, nodal relationships can operate with various levels of trust, including absolute trust, high trust, medium trust, low trust and completely trust-free environments. Unfortunately, as is with human relationships, nodal relationships can have nodes that exhibit trustworthy operation but can in time turn out to be untrustworthy (and vice versa).
There are a number of ways to establish trust among nodes. One commonly employed approach involves data exchanges that are carried out to verify authentic nodes. This can include the transfer of challenge values, hashes, secret information, timing values and other data that enable two communicating nodes to authenticate one another with an acceptable level of trust. In some cases, secret information, such as a private encryption key known only to trusted nodes, can be used as part of the verification process.
A group of authenticated nodes (devices) can be viewed as existing within a “trust boundary” so that all of the devices within the designated trust boundary are confirmed as being sufficiently trustworthy. This boundary can be established using security protocols that establish that all of the known elements within this boundary are trustworthy. Nevertheless, even in a trusted environment, data transfers between nodes are often encoded by, or appended with, additional security information to further enhance trust levels within the system. This provides an on-going assessment of trustworthiness of the system.
While operable, the continued reliance upon computer networks provides an ongoing need for advancements in evaluating and ensuring the trustworthiness of data communications among various nodes involved in data transfers. It is to these and other advancements that various embodiments are generally directed.
The present disclosure provides systems and methods for evaluating trust along a data path through a computer network. As explained below, some embodiments include a mechanism which assigns a trust level to each of a plurality of nodes in the network. Data are transferred through the network from a source node to a destination (end user) node along one or more selected data paths that involve one or more intermediate nodes. The trust levels of the various source, intermediate and destination nodes are accumulated and provided to an end user of the destination node in the form of a notification report. Various actions may be taken as a result of these reported trust levels of the nodes involved in the data transfer.
In some cases, a minimum specified trust threshold is required, so that nodes with trust levels below this threshold are avoided and do not form a part of the data path. In other cases, additional verification operations may take place as a result of the respective trust levels indicated along the transmission path. For example, if data are passed through a node with an unacceptably low trust level, additional steps are taken to validate the received data to compensate for the fact that an untrustworthy node was involved in the data transfer.
In still other cases, history data are accumulated to monitor various paths taken through the system, and these history data are used to take various corrective actions to expedite future data transfers with improved trust characteristics. A number of other alternatives are also contemplated and will be discussed below.
These and other features and advantages of various embodiments can be understood beginning with a review of
The host device 102 and the data storage device 104 can each take a variety of forms. Without limitation, the host device 102 may take the form of a programmable processor, a personal computer, a workstation, a server, a laptop computer, a portable handheld device, a smart phone, a tablet, a gaming console, a RAID controller, a storage controller, a scheduler, a data center controller, etc. The data storage device 104 may be a hard disc drive (HDD), a solid-state drive (SSD), a thumb drive, an optical drive, a tape drive, an integrated memory module, a multi-device storage array, a network attached storage (NAS) system, a data center, etc. The interface 105 can be a :local wired or wireless connection, a network, a distributed communication system (e.g., the Internet), a network that involves a satellite constellation, etc. The interface 105 can also be various combinations of these and other forms of interconnections.
The data storage device 104 may be incorporated into the client device 102 or may be arranged as an external component. For purposes of the present discussion, it will be contemplated that the host device 102 is a computer and the data storage device 104 provides a main memory store for user data generated by the host device. While not limiting, the memory 108 may include non-volatile memory (NVM) to provide persistent storage of data. As will be recognized by the skilled artisan, an NVM maintains data stored thereto even in the absence of applied power to the NVM for an extended period of time.
Generally,any node in the system can communicate directly or indirectly with any other node. The network 110 can be a private network, a public network, a high performance computing (HPC) network, a cloud computing environment, a software container system, the Internet, a :local area network (LAN), a wide area network (WAN), a satellite constellation, an Internet of Things (IoT) arrangement, a. microcontroller environment, or any combination of these or other network configurations. Local collections of devices can be coupled to edge computing devices that provide edge of Internet processing for larger processing-based networks. One such edge (E) device is denoted at 116.
The form and type of data transfer between the source 122 and the end user 124 is not germane to the present discussion, as substantially any sort of network communication can be used to transmit at least one bit from the source to the end user. As such, the data transfer may be the issuance of a simple command, the transfer of data from the source 122 to the end user 124 for storage at the end user node, a request to retrieve data stored at the end user, the initiation of the execution of a selected application, the launching and execution of a software container, a query of a data base, a status query, a trim command, and so on.
In some cases, requests issued by the source 122 result in a return path response that is subsequently forwarded from the end user 124 back to the source to complete the transaction. These requests and responses may take different paths through the network and can be viewed as separate, albeit related, transactions. For example, a first transaction may involve an initiator node (such as the source 122) directing a request to a target node (such as the end user 124), and a second transaction may subsequently involve the target node passing data back to the initiator node in response to the request. In this type of exchange, the initiator node may be the “source” node for the first transaction and the target node may be the “source node” for the second, follow-up transaction. The respective data paths taken between these nodes may be analyzed and processed separately or together in accordance with various embodiments.
In order to transfer these and other forms of data, one or more paths through the system 120 may be used. As used herein, a “path” is an indication of at least all intermediate devices (nodes) that were involved in the associated data transfer. The path can also include the source node and the destination node in at least some cases. A total of eight (8) intermediate nodes 126 are depicted in
Each of the intermediate nodes 126 in
It can be seen from
Depending on the configuration of the system, a large block of data to be transferred from the source 122 to the end user 124 may be broken up into smaller packets of fixed size, and these respective packets may be transferred via different paths through the nodes 126. Indeed, this is one of the advantages of distributed data communication networks (e.g., the. Internet, etc.), since redundancies and other mechanisms can be incorporated in the data transfer arrangement to ensure reliable receipt of the data by the end user node 124 from the source 122 through different intermediary nodes 126.
Various trust levels including A, B, C, D, E . . . , are established, monitored and used as data flows are provided from the source device 134 to the end user device 136, as indicated by data flow arrow 139. In some cases, the trust levels A and E of the respective source and end user devices 134, 136 may be taken into account by the operation of the trust manager 132.
Should a given source (e.g., source device 134 in
Each packet 140 accordingly includes a payload 142. and a set of trust data 144. The payload 142 can take any number of forms, but generally corresponds to the content of the data set (or that portion thereof incorporated into the packet).
The payload 142 can include a quantity of user data bits 146, error correction code (ECC) data 148, and control data 150. The user data bits represent the actual underlying data useful for the associated data set. The ECC can take any number of forms, including multiple layers of forms, such as but not limited to Reed Solomon codes, LDDC; (low density parity codes), RAID parity values, BCH (Bose—Chaudhuri—Hocquenghem) codes, etc. The control data 150 can provide information of substantially any type as desired including time/date stamp values, revision data, source data, etc.
The trust data 144 are appended to the payload data 142. and provide additional information of use by the trust manager 132 in
The trust manager 160 is shown to include various sub-circuits, including a protocol manager 162, a transport, manager 164 and a receipt manager 166. The protocol manager 162 operates as a front end to perform various front end operations prior to the transfer of data sets. This can include operations to establish various trust protocols via trust policy engine 168, maintain a system map 170, and generate or otherwise establish trust levels through the system via trust generator 172.
The trust protocols from engine 168 can be established internally or externally. As noted above, the engine 168 can be realized using hardware or firmware/software, so that the engine 168 can be implemented as a hardware circuit utilizing an array of gate circuits, or can be arranged as programming stored in a local memory that is executed by one or more programmable processors (CPUs). In some cases, the trust policy engine 168 is a software layer in a larger software OS system. Those skilled in the art would be readily able to implement the trust policy engine 168 in any number of operable systems. The foregoing description of hardware and software implementations applies equally to other aspects of the system.
Regardless of form, it will be understood that the engine 168 utilizes various internal and external inputs to arrive at metrics and control limits under which the system is to be governed. In some cases, user (customer/client) specifications can be utilized, so that specific quality of service (QoS) and other system specifications are established for use of the system. Substantially any level of security scheme can be implemented by the engine 168. Different security schemes can be utilized for different clients, different end users, different levels of data sets, etc.
The trust levels managed by the engine 168 can be established and expressed in any number of ways. For purposes of the present discussion, a sliding scale can be used so that, for example, a minimum level such as a Trust Level (TL) of 0 can be used to identify a completely trust-free node in which no trust is reposited, and a maximum level such as TL of 100 can be used to identify a completely trusted node in which full trust is reposited. Depending on the verification processes, history data and other factors, trust levels can be assigned anywhere from 0 to 100 for the various nodes. It will be appreciated that other metrics can be used; for example, a trust level of A can designate a first trust level, a trust level of B can be used to designate a lower, second trust level, and so on.
It follows that the protocols used by the engine 168 can require at least a minimum level of trust be established for the various data paths. A minimum threshold T of a selected trust level TL can be any suitable value, such as a value of T=50 on the scale from TL=0 to TL=100, etc. In this case, the system can be configured in some embodiments such that the data packets (e.g., 140,
Referring again to the example in
In further cases, data packets are allowed to flow through nodes haying trust levels below the specified minimum threshold. In this case, these data packets are subjected to additional verification operations at the back end to ensure trustworthiness. Using the previous example, data packets passing through node TL4 in
Continuing with
The transport manager 164 in
In some cases, the tracking module 176 can operate in conjunction with the trust policy engine 168 and the system map 170 to ensure that a particular path is taken through the network for a given data set.
A history log 176 accumulates data associated with the transfer of the packets through the system. This can be expressed as a data structure in a memory that provides various entries including data transfers, all of the nodes that were involved in such transfers, time/date stamp data associated with such transfers, trust levels associated with the nodes involved in the transfers, and so on.
The receipt manager 166 in
A report module 182 of the receipt manager 166 operates to generate a report, such as at the conclusion of a successful transfer of a selected data set, which summarizes the accumulated data. This may include a simple indication that all of the nodes involved in the transfer had trust levels that met or exceeded specified levels. More complex reporting may include statistical representations of how many and which nodes were involved in the transfer, the respective trust levels, and so on.
An action module 184 of the receipt manager 166 operates as required to take further actions if needed, such as providing an indication to the end user of unsafe transport conditions, additional verifications, and so on. 1n some cases, the trust manager 160 operates automatically to evaluate, generate and store reporting data and other information about the operation of the system. In other cases, the trust manager 160 can provide real-time notifications to a user via a suitable user interface. These notifications can allow the user to decide on an appropriate course of action as a result of the trust path taken to deliver the received data. The user may provide certain inputs via the user interface that, result in further operations that take place as a result of the data transfer operation. In this latter case, should a path be taken that does not meet system requirements, the user can decide whether to request a retransmission of the data along a more reliable pathway, can request that further authentication operations be applied to the received data to verify the data, and so on.
Having now provided a top level overview of the operation of the system, further details regarding trust levels will now be provided. As noted above, the concept of trust is a conceptual metric indicative of data security levels of individual components of an overall system. To this end, a variety of cryptographic functions can be employed to evaluate trust levels for various nodes.
Encryption algorithms such as used by block 192 essentially provide an encoding function so as to transform the input plaintext to an encoded form. In this way, information can be transmitted safely and the underlying contents cannot be easily discovered without the use of massive amounts of computational power unless knowledge of the key(s) is provided. Many forms of encryption are known in the art, including but not limited to symmetric key and public-private key encryption systems. Encryption systems are often implemented in software using programming stored in a local memory executed by a programmable processor, but other encryption circuit configurations can be used as well including gate logic, ASICs (application specific integrated circuits), FPGAs (field programmable gate arrays), etc.
A hash function is a mathematical algorithm that maps the input data of arbitrary size (e.g., the “message”) to an output value of fixed size (“hash,” “message digest,” etc). Hash functions are one-way functions so that it is practically infeasible to invert a hash output to recover the original message based on the output hash value. A number of hash functions are commonly employed in modern cryptographic systems, such as the so-called class of SHA (secure hash algorithm) functions including SHA-1, SHA-256, etc.
Because hash functions tend to be deterministic, are collision-resistant and can be easily calculated, hash values can be supplied along with a message to provide evidence that the data have not been tampered with since the time of transmission. This can be verified by recalculating a new hash value based on the received message and comparing the new hash value to the original hash value. Other cryptographic uses for hash values are well known in the art.
Many data security schemes apply multiple levels of processing to transmitted data; for example, a set of plaintext may be encrypted in accordance with
The sequence in
In response, the server 226 may provide encryption or other cryptographic processing to issue an authenticate TSI value to the TSI node 222. This authentication value may include some encoded form of the challenge value from the storage node 226. In response, an encrypted response, denoted as ENC(RESP), is forwarded back to the server 224. This response is processed as required by the server, and forwarded to the storage node 226.
This simple example illustrates how that individual devices can authenticate one another as part of a verification process. The various authentication data. exchanges can be attended by encryption operations using secret encryption keys, hash values, HVAC values, private-public key encryption techniques, etc. in order to ensure that the various devices are authenticated. The storage device might perform a hash function operation upon certain data or encrypt certain data using a secret key. If the responses received back from the other devices show evidence that these devices have access to the same secret key, provide responses that generate the same hash values, etc., a level of trust can be generated among these devices. For example, if the challenge value is a random sequence that is encrypted by the storage node 226 prior to transfer, and a subsequent response received back by the storage node includes an encrypted version of the random sequence that, once internally decrypted matches the originally issued challenge value, trust can be generated as a result. The resulting trust of the respective devices can be recorded and noted into the trust manager system 160 of
Centralized authentication mechanisms such as depicted in
Unlike the centralized approach in
A number of peer-level authentication mechanisms have been proposed in the art, including peer-level operations that may involve a local hub (not separately shown in
In
Maximizing the amount of entropy in a random number used in a cryptographic function tends to maximize the effectiveness of the function against attack. For example, the greater the amount of entropy contained in a cryptographic key used to encrypt data using a selected cryptographic function (e.g., an encryption algorithm, an HMAC function, etc.), the greater the difficulty in guessing the key or determining the key using brute force methods.
The entropy source 242 in
Trust has been discussed above, but now it can be understood that in at least some formulations, the term “trust level” can relate to the extent to which entropy in the output from an entropy source can be trusted. Trust level is based on a variety of factors. A storage device might treat the local entropy sources within its control as having a relatively high level of trust, since the entropy sources reside within the confines of its own system space (e.g.,“a local trust boundary”). A source outside this boundary, such as a host operating system (OS) entropy source that communicates with the storage device, might be treated as being less trustworthy.
Additional cryptographic trust boundaries may be formed within the storage device. For example, the storage device may view internal hardware based sources as more trustworthy as internal firmware based sources. This is based on the fact that new firmware can he loaded to the storage device, but the hardware characteristics of the device are dependent upon the actual hardware configuration of the device as manufactured. The greater the ability of external sources to influence a given bit string, the lower the entropy, and hence. the lower the trust. This is a truism that can be applied throughout any system.
It can be seen that entropy and trust levels are different, albeit related, concepts. A source that normally generates relatively high levels of entropy could be found to have a relatively low trust level, and a source that normally generates relatively low levels of entropy could be found to have a relatively high trust level. A number of statistical tests, certification protocols and hardening techniques are known in the art to evaluate both entropy and trust levels from a given source. Accordingly, it will be understood that the trust manager of
Referring again to
Some host OS level entropy sources can have a hardware component, such as specially configured circuits that generate statistically random noise signals based on various effects such as thermal noise, the photoelectric effect or other quantum phenomena, timing of certain events, the number of programming pulses required to program a flash memory cell to a particular value, etc. For example, a counter and timing system can be used to aggregate entropy values based on system events (e.g., keystrokes, system calls, etc.). The device FW entropy source 246 in
The device HW entropy sources 248 in
A trust manager is indicated at block 252. This trust manager generally corresponds to, but is not limited, to, the trust managers 132 and 160 discussed above. The trust manager 252 includes an entropy extraction module 254, a random number generator 256 and a trust level evaluation module 258.
The extraction module 254 takes the form of an entropy extractor adapted to extract entropy from one or more entropy sources, such as the sources 244, 246 and 248. Entropy extractors are known in the art, and will be understood to generally take low entropy inputs and manage these, through mathematical algorithms, to provide high entropy outputs, Statistical analyses can be applied to the outputs to further randomize, and hence increase the entropy of, the outputs of the system. By definition, the application of a hash function to a given input, such as described in
The trust manager 252 in FIG, 12 further includes a random number generator (RNG) 256. The RNG can operate to output one or more random numbers for use by the system in managing the security thereof. The random numbers generated by the RNG 256 can be generated in response to the entropy supplied by the various sources 244, 246, 248 and 250. The random numbers supplied by the RNG 256 can be true numbers, pseudo-random numbers, or random numbers that approximate true random numbers. These random numbers can be utilized by the system in a number of ways including in the generation of encryption keys, nonce values, challenge values, etc.
A trust level evaluation module is indicated at 258. This module operates to evaluate various trust levels of upstream nodes, such as during a data transfer operation. Outputs from the trust manager 252 in
From a physical standpoint, the data will flow from the source to the end user, most likely in a very highly efficient manner. However, from a trust standpoint, the flow will encounter nodes having potentially widely different trust levels, as indicated by
As noted above, in some cases the most relevant aspects of the data flow 262 will be the extent to which data flowed through low trust zones 266, in which case corrective actions can be taken. However, per QoS specifications, routing decisions can be made such that the availability of nodes within high trust zones as indicated at 264 (and, to a lesser extent, the nodes in the medium trust zones 268) can be distributed so that, en toto, data transfers have at least an average available level of trust during the associated transfers.
Generally, as noted above the processor 274 is a programmable processor configured to execute program instructions provided from a local memory, such as the local embedded memory 274. The cryptologic circuit 276 performs a number of different cryptographic based functions, including but not limited to those crypto functions described above in
The keystore 278 is an embedded hidden memory, whether previously programmable (e.g., ROM, or read-only-memory), write-once memory (such as in the form of OTM or one time programmable memory elements), rewriteable memory, and so on that is used to store hidden data including but not limited to encryption keys and other cryptographic information. The keystore 278 allows cryptographic information, such as embedded encryption keys, to be stored internally within the SOC 270 and processed by internal circuitry such as the cryptologic circuit 276 without providing the ability of an attacking party from accessing signal paths that may access or influence the cryptographic operations being carried out to enhance entropy and trust in accordance with the present discussion.
The SOC 270 can operate in accordance with external memory 280 to temporarily transfer and store data. The external memory 280 can take any number of desired forms including DRAM, flash, etc. An interface (IIF) circuit 272 enables the SOC 270 to communicate with external nodes within the system. These and other mechanisms can he used to enhance trust of a given node.
At block 302, a trust policy is established. This trust policy can take a number of forms. In some cases, the trust policy can require every node that passes the data be subjected to a highest level of trust. This can include centralized authentication as described above in
The granularity of trust utilized in the system can be specified as required. In some cases, a trust policy may allow entropy to be used by various levels of system configurations while not allowing entropy to be used by other levels of system configurations. For example and not by way of limitation, sonic trust policies may allow system hardware resources be used to generate entropy (e.g., as in
It will be appreciated that some types of data may be subjected to a first level of trust policy through the network while other types of data may be subjected to a different, second level of trust policy. Regardless, it is contemplated that the actual trust levels of the various nodes involved in any particular transfer will be recorded, allowing the system to take appropriate follow--on actions as required once the data are received at the end user node. It is possible that a given node may have multiple trust “scores” based on different operations involved in verifying that particular node. Stated another way, a particular node may be able to provide data services (e.g., the receipt, processing and/or passage of data sets) with different trust levels depending on different internal configurations.
Continuing with
Block 306 in
The selected data set is transferred through the network at block 312. During such transfer, path and trust data are accumulated as indicated at block 314. The transferred data are received at the destination (end user) node at block 316. A trust report is generated and provided coincident with the receipt of the data at block 318. As described above, the trust report includes various types of control data including an indication of the path(s) taken by the data set en route to the destination location, along with information relating to the trust levels of the involved nodes.
As indicated by block 320, various corrective actions are taken as required s a result of the trust report at block 318. This can include additional verification operations, the re-transmittal of data, the calculation of HMAC or other values, and so on as required to verify the data received are trustworthy, irrespective of the trust levels of the source and/or intermediate nodes involved in the data transfer.
The data storage system 400 is a mass-data storage system in which a large population of data storage devices such as 104 (
The system 400 includes a storage assembly 402 and a computer 404 (e.g., server controller, etc.). The storage assembly 402 may include one or more server cabinets (racks) 406 with a plurality of modular storage enclosures 408. While not limiting, the storage rack 406 is a 42U server cabinet with 42 units (U) of storage, with each unit extending about 1.75 inches (in) of height. The width and length dimensions of the cabinet can vary but common values may be on the order of about 24 in.×36 in. Each storage enclosure 408 can have a height that is a multiple of the storage units, such as 2U (3.5 in.), 3U (5.25 in.), etc. to accommodate a desired number of adjacent storage devices 134. While shown as a separate module, the computer 404 can also be incorporated into the rack 406.
The modular nature of the various storage enclosures 408 permits removal and installation of each storage enclosure into the storage rack 406 including under conditions where the storage devices 104 in the remaining storage enclosures within the rack are maintained in an operational condition. In some cases, the storage enclosures 408 may be configured with access panels or other features along the outwardly facing surfaces to permit individual storage devices, or groups of devices, to be removed and replaced. Sliding trays, removable carriers and other mechanisms can be utilized to allow authorized agents to access the interior of the storage enclosures as required.
The system 500 includes a client node 502, which as described above can operate as a user device to initiate a request to carry out an application or other operation in a distributed storage environment of which the system 500 forms a part. The request is forwarded to a request scheduler 502, which operates to manage the request, as well as additional requests, supplied to the system.
A server node 506 represents an application aspect of the overall distributed storage environment, and can include various elements including a server controller 508, a storage array 510, a service log 512, a service monitor 514, and a service application 516. These respective elements can operate as described above to perform operations responsive to the various requests issued to the system as well as to accumulate and process performance metrics associated therewith. The service application 516 can represent data and programming instructions stored in the storage array 510, or elsewhere, that are operated upon as a result of a service request issued by the client node 502 and forwarded to the server node 506 by the request scheduler 504.
It follows that the various mechanisms within the system are well adapted to establish and monitor trust levels for nodes involved in the data transfers carried out from a source node to an end user node. The trust manager configurations disclosed herein provide real-time indications of paths taken through the system as well as up-to-date trust levels of the intermediate nodes. Corrective actions can be taken as required to ensure that the received data meet the requirements of a given specification.
It is to be understood that even though numerous characteristics and advantages of various embodiments of the present disclosure have been set forth in the foregoing description, this description is illustrative only, and changes may be made in detail, especially in matters of structure and arrangements of parts within the principles of the present disclosure to the full extent indicated by the broad general meaning of the terms wherein the appended claims are expressed.