
These White Papers have been created to give better insight into the unique and disruptive technology being developed at WhiteStar Communications Inc. Each Paper breaks down a different topic to explain the unique problems we are facing and the novel solutions being developed by WhiteStar to address those problems. These Papers are divided into four main categories: Security, Networking, IoT, and Education. Click on one of the links below to learn more.


Technology White Papers

Business of IoT

IoT Cars

IoT Sitrep

Compliance Networking

Interplanetary Networking

The WhiteStar Network

WhiteStar vs. Blockchain

Cryptography

Intellectual Property

Security Architecture

Security First

Supply Chain

System Surface Area

WhiteStar Culture

A major concern with the proliferation of seemingly “free” cloud based services, as well as IoT devices, is their impact on one’s expectation of privacy. We expect our homes to be private, a place where we relax and live our lives at ease. However, there is a growing uneasiness that the IoT devices we bring into our homes compromise that expectation of privacy; after-all these devices are littered with a dizzying array of sensors which, if misused, could compromise a person’s privacy in almost every conceivable way. \
\
Unfortunately these concerns are not necessarily misplaced. The business of IoT as it stands today not only involves the sale of the device itself, but also the exploitation of the data and metadata gleaned from that device. In fact, IoT device manufacturers have every incentive to capture as much data as possible due to the business model of profiting on the sale of access to that data. While a major consumer of this data are advertisers, some manufacturers sell it to institutions, governments, and anyone who is willing to pay for it for their own uses. Regardless of where their data ends up, consumers are correct to be concerned about their IoT devices because the business model of the device manufacturers isn’t a benevolent one of making our lives easier. Selling the devices themselves is a one time transaction with slim profit margins while selling of the data that comes out of our homes is a highly profitable recurring revenue stream, regardless of the privacy implications.

###### This is further complicated by the limitations of the IoT devices themselves.

While manufacturers may make some effort to avoid collecting data from minors, devices cannot differentiate between a child and an adult with absolute accuracy. Therefore they cannot determine whether the person, whose data is being collected, can legally consent to the data collection itself. Despite this, IoT devices in the home often collect data from minors, violating the privacy expectations of society’s most vulnerable population - our children. We believe that data collection from vulnerable people, including children, is unethical.  We also believe that the expectations of privacy in the home are directly incompatible with the current business model of monetizing the data collected by IoT devices.\
\
Sadly, companies that make IoT devices are heavily dependent upon revenue from the collection and monetization of user data. It serves as fuel for the engine that drives their true source of revenue - advertising (or something even worse). While advertising is not necessarily a bad thing, the direct targeted advertising models employed by social media and tech companies require the bulk collection of almost every piece of data and metadata a person generates. Done properly, it’s extremely successful, and can effectively generate more sales than any other type of advertising. Companies who want to advertise know this, and have a strong demand for the data being collected. This creates a vicious cycle where companies who want to leverage targeted advertising drive the collection of more and more data, and companies which can provide the data seek new ways - including with IoT devices - of procuring the data to gain insight into people’s lives. This, in turn, drives technical decisions on how to best collect and store this data and to support this business model.

The model has pushed companies toward massive Cloud storage and processing of user data, prompting enormous investments of capital and manpower into the development of expensive centralized repositories of compute power and storage. This becomes a self-perpetuating cycle, where the company now has to generate sufficient capital to upkeep their Cloud backend by data-mining more data to sell more ads, which requires the perpetual addition of more Cloud storage. All of this is built on the ability to gather information from the end user, and again, leads to the creation of increasingly creative ways of gaining insight into a person’s personal life.

###### Two things are necessary to break this dangerous cycle - a shift in business model simultaneously coinciding with a shift of storage and compute to the end device. 

WhiteStar’s business model directly rejects what we believe is unethical data gathering practices, and instead embraces a direct sales model. Our users, and their data, are not our product. Ordinarily IoT devices, if not subsidized by the revenue generation of user data collection, would be prohibitively costly. This is where WhiteStar’s novel and patent pending technologies allow for a paradigm shift in storage and compute away from the expensive Cloud to the user end-device, alleviating the need to monetize a user’s data.

Replacing the traditional business model of advertising facilitated through data mining, WhiteStar instead charges a small monthly fee for a subscription to all of its services, including access to, and control of, a user’s IoT devices. This small cost is due in large part because WhiteStar’s novel architecture results in dramatic reduction in the cost of the network and its’ resultant infrastructure. This reduction creates the opposite feedback loop of cascading effects, ultimately cumulating in the complete obsolescence of the need to gather user data. Put in other terms, this allows devices that utilize WhiteStar to not only deliver a less expensive service, but also promotes a transformative shift in the need to collect user data.

We accomplish this shift via the WhiteStar Network Operating System allowing devices with WhiteStar enabled apps to function as their own “Cloud” at the edge of the network. This eliminates the need for a centralized repository of information and compute power. By taking advantage of the beyond Moore’s law expansion in compute and storage capabilities at the device level, WhiteStar is able to directly connect a user’s mobile device to their IoT devices via a hybrid peer to peer network. We achieve this via WhiteStar’s Cohort technology, in which devices form a first-party trusted network with full attestation and security. By leveraging WhiteStar’s hybrid architecture, we alleviate the need, and cost, for IoT manufacturers to acquire technical expertise in building and maintaining a Cloud backend while also eliminating the need to monetize their users by mining and selling their private data.

One of the biggest problems with today’s modern cars is the technology integrated into them, or more specifically, the security of the technology integrated into them. While consumers often complain about outdated and outmoded technology, which can’t be upgraded after a purchase, they seldom think about the technology’s security measures becoming obsolete over time. Technology in cars has become increasingly powerful, with features like lane keeping and changing assistants, autopilot, radar-guided cruise control systems, automatic parking, etc. While these features certainly help drivers to avoid accidents, the underlying technology is vulnerable to misuse which poses an enormous liability.

There have been notable incidents in the news of a cars’ technology being hacked, and essentially turning the car itself into a missile on the road, with the occupants being completely helpless inside. Sadly, as the automotive world becomes increasingly reliant on connected technologies, these kinds of exploitations will inevitably become more common. While some manufacturers may properly secure their systems against such intrusions, it’s also certain that many will not. A car manufacturer’s expertise is in building cars, not securing the devices and networks that are used to connect to them.

This leaves drivers exposed to the dangers of an unsecured vehicle that could potentially harm them and others. This also opens manufacturers up to an enormous amount of liability, which could harm their sales and business. As we continue to develop increasingly more complex and technically integrated vehicles, the cybersecurity models that secure those same vehicles against malicious attack must radically improve in parallel.

A solution to this problem is WhiteStar Communications Network Operating System (NOS) which allows devices to connect to each other, with complete security, over the smallest network attack surface area as possible. WhiteStar’s cryptographically secure NOS solves the issue of how to both securely connect devices within a vehicle, in addition to securely connecting externally to the vehicle itself. The beauty of the WhiteStar NOS lies in its’ simplicity. Devices connect together via a secure hybrid peer-to-peer overlay network allowing for full first-party trusted communication without a cloud infrastructure. We call this technology Cohorts and it’s one of the many patented security features used by the WhiteStar NOS. The heart of the WhiteStar Cohort protocol, in which devices create relationships based on unique exchanged key-pairs that roll on each packet, prevents unwanted devices from attaching to the network and controlling devices they don’t have permission to control. This system is detailed in the security section of our website. 

If you think of an individual car as its’ own intranet, it is possible to use WhiteStar’s Cohort protocol to connect devices together within the car, allowing them to function in tandem with complete security. This is a powerful way of securing devices on a small scale, but WhiteStar also secures the car’s connectivity with the internet at large. The Cohort system will allow a car to create a secure connection with the rest of the internet, meaning the car can safely connect to services that provide GPS guidance, music and video streaming for entertainment, remote diagnostics and software updates. WhiteStar eliminates any potential attack vector for remote tampering with the vehicle by fully securing all inputs into the car’s internal network, and also simultaneously protects the connectivity between the devices within the car.

One of the best aspects of the WhiteStar NOS from a developmental perspective is its’ ease of implementation. Since it’s an overlay network, it’s adaptable to most existing hardware as a software upgrade. Plus, WhiteStar natively communicates with both mobile phones and IoT devices, making it the perfect communications fabric for device-to-device and man-to-device communications. This means automakers save valuable time and money simplifying the development process of the software that goes into their vehicles, and with WhiteStar at the heart of their system, security is baked right into that fabric. Automakers no longer worry about securing a costly Cloud backend with all the liabilities inherent to storing and processing sensitive data. Instead WhiteStar devices form networks from the edge, eliminating the need for the Cloud entirely. \
\
WhiteStar’s ability to operate without a centralized Cloud system also helps drive costs down for device manufacturers who are increasingly cost conscience with respect to Cloud enabled services. Clouds represent a high recurring cost to automakers, who pass those costs along to customers in the form of subscriptions. Often connectivity services are extremely expensive in cars leading customers to opt out of purchasing them for their vehicles. WhiteStar is very inexpensive to implement, leading to a vastly reduced cost of delivering Cloud-like functionality to customers, potentially opening up new customers who would pay a previously unobtainable lower price, or offering connectivity services for free.

###### One of the biggest problems with IoT devices currently is their dependence on the Cloud for processing and storage of information.

This is predominately evident in the current smart home device market. For example, in order to deliver a video feed from a connected camera to a mobile phone anywhere in the world, device manufacturers have chosen to take the data and metadata gathered and push it back to their own Cloud backend. This presents serious privacy and end device security concerns, along with the challenge of handling and securing of the data collected. That said, there’s also another major issue with this paradigm, notably maintaining a Cloud infrastructure to host the data is extremely costly.

Currently, some of the major players in the IoT space monetize the data gathered by their smart home devices to offset the cost of delivering the service. Data is collected in bulk and access to this data is then sold to interested parties. (A recent example being access to a certain doorbell camera vendor’s data being sold to law enforcement). The collected data is also used for internal marketing purposes to more accurately predict the products a given consumer would likely purchase, as well as serve targeted advertisements to drive revenue in other areas of their business. Effectively, the IoT device serves as a loss leader to help increase the overall value of the customer without being directly profitable.\
\
While most consumers are justifiably concerned about the use of their private data for marketing purposes, an even greater concern is the collection of data from areas of the home they consider the most private. Many people feel uncomfortable having cameras and microphones in and around their homes knowing that the video and audio gathered by these IoT devices will be sent to an external repository and potentially retained indefinitely. This lack of trust creates a barrier to consumer adoption of IoT technologies and fundamentally breaks the value proposition of the device itself. Not only are these devices expensive, and the backend services for those devices are expensive to setup and maintain, consumers feel these devices compromise their privacy, inviting strangers to watch their families for profit, in their most private space: their homes.

Despite the barriers to adoption, the IoT and smart device market is growing rapidly, possibly to ethereal asymptote. Consumers are clamoring for the latest devices to put in their homes because they see the value in being able to monitor their houses while away, conveniently lock and unlock their doors remotely, and change their indoor lighting to suit their needs or mood. However, this market would expand much faster, and with greater force, if the cost of IoT products were lower, and there were no privacy or security concerns with the devices or the data they collect. The fact of the matter is these devices enhance the quality of life, which is enough to offset some of the downsides they present. Addressing those barriers of adoption will lead to an explosive increase in consumer adoption, resulting in a true market disruption. \
\
In order to fully realize this vision however, the Cloud, (which serves as an impediment to delivering more affordable products and lacks the adequate security and privacy), must be severed from the equation. As previously mentioned, the Cloud is absolutely necessary under the current paradigm in order to maintain today’s business model of IoT, since a large portion of the revenue garnered by businesses doesn’t actually come from the device itself, but rather from selling the metadata gathered by those devices. In fact, it’s the monetization of the collected metadata that truly drives profitability for today’s IoT companies.

###### WhiteStar’s vision for IoT is a complete market disruption for the entire IoT space, one that results in a fundamental shift away from the Cloud into edge networking and compute.

The WhiteStar Network Operating System (NOS) not only provides device manufacturers with an IoT solution that is orders of magnitude more affordable than Cloud-based platforms, but also provides the best protection for user privacy along with an overall reduction in complexity. The WhiteStar NOS is a proven technology allowing device manufacturers to connect users and devices with WhiteStar’s hybrid peer to peer network and form their own networks, via the WhiteStar Cohort Architecture, with first party trusted devices. \
\
In WhiteStar parlance, devices exchange unique key-pairs with each other when connecting, allowing them to be whitelisted into a relationship with other known and trusted devices and users. This permits users to communicate directly via peer to peer connection, with end-to-end cryptography, and a suite of complimentary content management tools. For the IoT space, WhiteStar’s Society mobile app allows users to create “scenes” and connect smart devices to a scene, which in turn sends real-time data directly to the user's smartphone. Allowing others to view the output from these devices is as simple as adding more human users to the scene. Furthermore, removing shared information from a human user is done by removing the user from the scene, the same way one would control a private conversation on Society.\
\
WhiteStar allows device manufacturers to define the type of device they’re creating along with a command set and controls for their device. When adding one of these devices as a connection, the device will transmit these details to the user’s Society app which will assemble the user interface and controls for each device. This permits users to manipulate devices with a tailored user experience. WhiteStar enabled devices also understand natural language commands, allowing users to speak directly to devices in their own words. This helps to overcome the complexity of understanding how to program or operate devices while also making the devices more accessible to those with disabilities.

While WhiteStar’s approach could be interpreted as a major problem for current IoT device manufacturers who rely on monetizing the data they gather, a huge advantage of leveraging WhiteStar’s hybrid peer to peer architecture is that it alleviates the need for these manufacturers to acquire technical expertise in building and maintaining a Cloud backend. It also means that no user data is ever stored in a Cloud thus removing the requirement to protect that data. This results in an order of magnitude reduction in cost to the device manufacturer allowing them to concentrate on what they do best, build IoT devices. \
\
Utilizing the WhiteStar NOS allows legacy device manufacturers to overcome the cost, privacy, security, and complexity barriers of adoption in the IoT space. WhiteStar’s technology simultaneously expands the size of the IoT market as well as disrupting the Cloud-based IoT device manufacturers. In doing so, a paradigm shift will occur where Cloud-based solutions will be forced to compete against newcomers in the market that are able to provide the same functionality, securely, at a fraction of the cost, with no degradation in quality of service and no increase in complexity. WhiteStar offers manufacturers a credible alternative to operating a Cloud backend with no downside and with significant benefits, making it the obvious choice for connecting IoT devices.

One of the most crucial aspects of WhiteStar is how it enables third party manufacturers to create value with WhiteStar enabled devices. Rather than simply being a proprietary solution, WhiteStar functions as a platform upon which other manufacturers can build services and products, all with seamless interoperability and security. While today’s devices can certainly adapt to using the WhiteStar Network today, it’s really the devices and services of tomorrow, the ones that haven’t been thought of yet, that will truly unlock the potential of a scalable, secure and simple IoT ecosystem. \
\
WhiteStar’s unique capability to connect users with devices in a flexible and transient way enables novel capabilities. For example, managing the smart devices at vacation rental property would be as easy as connecting the renter’s smart phone to WhiteStar enabled smart home devices when they check in. This would allow the renter to have private and secure access to those devices for the duration of their stay. At checkout, the property owner would remove that connection, removing all information collected by those devices from the renters device. This brings value to the rental property owner, enabling a better customer experience while maintaining the privacy of the renters.\
\
Another scenario where WhiteStar’s solution brings value is to the home security monitoring market. With WhiteStar enabled devices, a home security company can monitor all devices in a home without having to build the Cloud infrastructure to store all the data. For the homeowner it would ensure that their data is not insecurely stored in a central location. If the homeowner no longer wants to employ the monitoring company, the homeowner can simply remove the connection, which in turn removes all data shared with the monitoring company from their devices, thus preserving the homeowner’s privacy. \
\
WhiteStar’s overlay network is compatible with any wired or wireless network, meaning WhiteStar enabled IoT devices are appropriate in places where other devices may not work making installation straight forward. That said, there will always be a demand for professional installation, especially coupled with monitoring or more complex smart home systems.

Pandemic-induced remote work can cause serious headaches for businesses trying to stay afloat in a challenging environment, especially when it comes to maintaining compliance with information handling. Lawyers, accountants, financial advisors and brokers, educators and healthcare professionals, just to name a few, all have legal obligations to make a best effort to protect the information of their clients. However, due to the distributed nature of today’s work places, this can be an extremely daunting task.
<br></br>

<Center>
<h4>A few of the more common compliance requirements: </h4>
</Center>

<dl>
<div class='col icon-box'><i class='fas fa-school'></i><h4>FERPA</h4><p>The Family Education Rights and Privacy Act of 1974. Gives parents access to their child's education records, an opportunity to seek to have the records amended, and some control over the disclosure of information from the records including ID’s, grades, email addresses, etc.</p></div>
<div class='col icon-box'><i class='fas fa-clipboard-check'></i><h4>PTAC</h4><p>Privacy Technical Assistance Center.  Government resource for dissemination of educational privacy and security compliance.  Provides training on FERPA and related requirements as well as data security best practices.</p></div>
<div class='col icon-box'><i class='fas fa-syringe'></i><h4>HIPAA</h4><p>Health Insurance Portability and Accountability Act.  Controls access to medical records.  This also applies to student's records held by schools.
</p></div>
<div class='col icon-box'><i class='fas fa-globe-europe'></i><h4>GDPR</h4><p>General Data Protection Regulation.  Defines what is personal data and how it should be protected and rights to have it removed. 
</p></div>
<div class='col icon-box'><i class='fas fa-child'></i><h4>COPPA</h4><p>Children’s Online Privacy Protection Act.  Governs collection of information for children under 13 years of age.  Requires parental consent.  Limits data collection and distribution.  Rights of erasure.
</p></div>
<div class='col icon-box'><i class='fas fa-globe-americas'></i><h4>CCPA</h4><p>California Consumer Privacy Act.  Aims to increase transparency for California residents, allowing them to understand how their data is collected and transacted.
</p></div>
<div class='col icon-box'><i class='fas fa-money-bill-wave'></i><h4>SOX</h4><p>Sarbanes-Oxley Act.  Mandates how financial record keeping and reporting must be handled for corporations.
</p></div>
<div class='col icon-box'><i class='fas fa-credit-card'></i><h4>PCI-DSS</h4><p>Payment Card Industry Data Security Standard governs how credit card information is handled.
</p></div>
</dl>

How can businesses quickly and easily set up communications and networking infrastructure that will facilitate compliant communications, without the overhead of a massive IT staff, and potential for human error, that expose the organization to legal and civil liability for failure to comply with data protection regulations? Moreover, what is the best practice when it comes to the state of the art of protecting information?

WhiteStar Communications has developed the

<Tooltip label='WhiteStar or WhiteStar NOS for short' to=''>WhiteStar Network Operating System</Tooltip>

, which enables businesses to quickly and easily deploy secure networks that are scalable, reliable and minimize human error.  The WhiteStar NOS is not just fully compliant with all best practices for data protection, it is in fact *the* *best* choice for securing sensitive data in-flight and at rest.\
\
WhiteStar’s hybrid peer to peer architecture allows sensitive data to be sent from one place to another with the absolute minimum attack surface area, thus ensuring no devices have access to sensitive data when they shouldn’t.  This is accomplished with WhiteStar’s patent pending Cohort system of first-party trusted connected devices. Likewise, WhiteStar functions with secure cryptography that protects all user data within the network of trusted devices.

WhiteStar accomplishes full information data handling compliance without the risk of exposure to

<Tooltip label='Man-in-the-Middle' to=''>MITM</Tooltip>

attacks, which are possible with other networking protocols and architectures. These attacks occur on networks when a cybercriminal inserts a device to mimic the intended destination for the packets being sent, thus tricking the client into thinking the erroneous device is the intended destination. This allows the malicious device to complete a

<Tooltip label='Process that kicks off a communication session that uses TLS encryption' to=''>TLS handshake</Tooltip>

with the sending device enabling it to further intercept and decrypt packets. With WhiteStar Networks, since all end devices are known and trusted, a MITM attack is not possible.\
\
The current data compliance paradigm requires corporate data to be decrypted for data monitoring and retention, but this introduces security risks that are inherent in the technologies and protocols being used to maintain the compliance. That’s why WhiteStar's solution is so revolutionary; the WhiteStar NOS’s Cohort maintains first-party trust deliberately whitelisting each pair of connected devices through an exchange of unique key-pairs and allowing only those trusted devices to have access to information via patent pending Crypto Tag Switching. Keys roll on each packet, which contains the possibility of a data leak if a key-pair is ever compromised, to a single packet.\
\
The WhiteStar NOS is available in both Java and C++ implementations and can run on both mobile and desktop devices. The StarFury REST API integration allows the technology to be adapted to existing web applications as well. This means users can interact with WhiteStar enabled devices via a host of applications, like WhiteStar’s Society: Secure Social Network application which delivers secure instant messaging and public communities of interest.

In addition to providing a complete information data compliance solution, the WhiteStar Network eliminates the need to pay for costly

<Tooltip label='Virtual Private Networks' to=''>VPNs</Tooltip>

that slow down data transfer and deteriorate the quality of the end user experience. It’s important to also note that users may not understand that VPNs do not guarantee secure end-to-end communications; they only secure the tunnel to the VPN concentrator typically located at the edge of each network. This means that a VPN potentially only offers protection for the first hop in the network, but could leave data vulnerable to exposure for any subsequent hops. These vulnerabilities are difficult to understand for the average layperson, thus the likelihood they’ll make a mistake when using a VPN is much higher. This, on the other hand, is not an issue when using a WhiteStar enabled application, which essentially makes a VPN obsolete.\
\
Today the

<Tooltip label='Transport Layer Security' to=''>TLS</Tooltip>

protocol is the primary means of protecting network communications over the Internet. It, (and its predecessor, Secure Sockets Layer or SSL), has been used for decades in many applications, but most notably in browsers when users interact with HTTPS websites. However, there are some inherent risks with the way TLS is typically deployed: requiring only one-way authentication and not two-way. This means only one party, (the server,) must prove its identity but not the client. This introduces the potential for transaction fraud.\
\
The same issue is true when considering most other applications that run over standard TLS. Despite negotiating an encrypted handshake, TLS only ensures that the first hop in the data’s path is somewhat secure, but does not necessarily protect any subsequent hops.\
\
WhiteStar ensures that data is encrypted with a two-way authenticated key-pair that prevents data from being read by any device other the device it was sent to or from. Unlike a VPN, this pairwise encryption extends end-to-end from the source device to the destination device and through every node that the user’s packets traverse. No node between the source and destination has the keys necessary to decrypt the packet. This packet forwarding technique is accomplished by way of WhiteStar’s patent pending [Crypto Tag Switching technology](/whitepapers/security/intellectual-property).

###### In simple terms, the WhiteStar Network is a hybrid peer-to-peer network.

It attempts to send encrypted packets by way of a peer-to-peer connection between devices by default. In the event packets cannot be sent directly, for example if one device is behind a firewall and the two endpoints need to negotiate

<Tooltip label='Network Address Translation / Port Address Translation' to=''>NAT/PAT</Tooltip>

, the WhiteStar Core provides a routing service so connectivity can be established. Most importantly, the WhiteStar Core has no visibility either into the data within packets or about the final destination of the packets that are sent over the network, nor the final destination of those packets. This is accomplished with Crypto Tag Switching, which is appending packets sent by one endpoint to another with a cryptographically signed key. Each hop in the network can attest to the next hop the validity of the packet. In a network assembled of first-party trusted devices, this allows for extremely secure communication whereby every packet was verified by the next device in the transmission path, but nothing in the payload was decrypted. At the end of this chain, packets make their way to the end device and are then decrypted finally using the private key held by the end recipient.\
\
Additionally, encryption keys are rolled on every packet, meaning the potential exposure if a set of keys are leaked, is no larger than a single packet. Normally this would require a massive amount of computational overhead to implement at scale, but WhiteStar shifts the computational burden of cryptography to the end device and the WhiteStar Core never has to handle encryption or decryption, or the verification of the signature of a previous hop in the network. This allows the WhiteStar Network to scale nearly indefinitely, unlike a traditional Cloud backend with TLS.\
\
WhiteStar’s system also prevents MITM attacks, Replay attacks, and does not require opening pinholes in a firewall. Each packet is given a unique encrypted temporal key, which is signed onto a payload of packets moving from one device to the next. This temporal key is checked against each device’s known previous temporal keys to determine whether a packet is part of a malicious Replay attack using another one of WhiteStar’s patented technologies. If the temporal key matches a known key, the packet is determined to be part of an attack and dropped. The key-pair exchange of the Cohort also applies to Replicators within the WhiteStar Core.  Because packets are never decrypted at any point in flight across the WhiteStar Network, MITM attackers cannot intercept a decrypted packet at any point during the movement of packets because they are only fully decrypted by the end device.

Coming full circle, most regulatory requirements for data-handling are open ended, mandating compliance with best practices within any given industry. Until the introduction of WhiteStar’s Cohort system, those best practices were defined as AES-256 encryption between TLS or TURN networking implementations on Cloud servers, which would have information pushed to the client side and protected in silicon on the end device. However, the Cohort system now provides a credible and more secure alternative to those best practices, redefining the standard by which network security is measured. Given the dramatic paradigm shift caused by this system, it’s fair to say the WhiteStar NOS is the new best practice for any secure networking implementation. Conversely stated, any networking implementation that doesn’t include WhiteStar is no longer in compliance with the letter of the law. 

Lastly, it’s important to note that WhiteStar can understand a bevy of rich lifecycle policies that determine how long data is retained using a patented life cycle management system. While most data regulations have a prescribed lifecycle, there are currently no networking protocols that have a concept of lifecycle - instead this is left up to the application or end user to manage. WhiteStar’s life cycle management system shifts the burden of data retention from the application to the network by immutably signing each object upon creation and imbuing it with a set of properties that define ownership and lifecycle, which can include things like a birth and death date.

This creates a form of

<Tooltip label='Data Retention Management' to=''>DRM</Tooltip>
, which is managed by the WhiteStar NOS, enabling users to fully control the information they create using a WhiteStar enabled application.  This functions even with account deletion, which WhiteStar handles as a service called Zeroization.

WhiteStar’s patent pending Zeroization feature cryptographically deletes and removes the ability to view any content created by a user who has Zeroized their account. Because account management is also handled by WhiteStar, the NOS can zeroize any piece of data sent by an account to any other device within its Cohorts where the data was shared using a specialized protocol.  Once data has been zeroized, it impossible to forensically recover.

###### Data creation, availability, modification, and deletion is always dictated by the end user on WhiteStar Networks.

Users can remove or modify data at any time and the network will enforce those alterations. This allows for data to be corrected easily or removed for any reason the end user deems necessary. However, it’s important to note that this is handled at the network layer, not the application. The WhiteStar Network functions without the need for a Cloud-based database as a central repository of information as all data is held at rest on end user devices. 

One of the major benefits of moving content management into the network layer is how it handles the future growth and obsolescence of end user device technology. Devices can become inoperable for any number of reasons, either from damage or something as mundane as an operating system or application no longer being supported by the provider. This can cause data that was sent from those devices to be perpetually “in flight”, making it impossible to delete that data, creating a regulatory and information security risk. 

This can also be an issue with certain secure Cloud-based client-server applications where access to data is based on private keys stored at the end device level; if access to those keys is ever lost, without any kind of proper recovery mechanism there is no way to identify and delete data that is beyond its’ retention time. This is a particular issue with things like encrypted messaging platforms that utilize Cloud backends, which retain data pushed to the Cloud that can only be altered or retrieved by verifying a set of private keys. Without a lifecycle policy in effect, data pushed to the Cloud cannot be removed and lives on those servers indefinitely. WhiteStar’s patented lifecycle policy management automatically solves this issue at the network layer, allowing for sensitive and regulated information to be automatically deleted at the appropriate time without the need for user input, future-proofing the network.

The WhiteStar Network is a proven solution, employing patented technologies to provide a revolutionary solution to organization’s most vexing problems for securing client data and maintaining regulatory compliance for years to come.

###### Mankind is on the verge of becoming an interplanetary species.

As humanity expands into high orbit, the moon, other planets, and eventually the stars, we must consider that our current networking technologies (the Internet) will fail to meet our communications needs. There are a myriad of complications associated with attempting to adapt legacy internet for interplanetary communications, but the two most glaring are those of distance and obstruction.

###### No matter how much technology improves, the laws of the universe prevent any signal transmission from exceeding the speed of light.

On Earth, distances are relatively short, so this delay in transmission is negligible, but as the distance between end points grows, these delays will increase dramatically. Communication with a geostationary satellite in orbit, a mere 22 thousand miles above earth, already introduces significant delay on the order of hundreds of milliseconds. The distance between the Earth and Mars can range from 36 to 249 *million* miles, resulting in delays between 3 to 23 *minutes*, even at the speed of light. Under such conditions, legacy internet would simply fall apart. \
\
The workhorse of the internet today is the HTTP protocol which runs over a TCP connection.  TCP uses “end to end” ACK’s of IP packets carrying information.  A sending device transmits packets, then “waits” for ACK’s from the remote end before sending more packets or possibly re-sending lost packets.  TCP will simply fail under such conditions.  One layer higher, HTTP also has time constraints.  Modern web resources often depend on back-and-forth life cycle communications between the client device and the server.  For example, several back-and-forth exchanges are required to negotiate content types, compression protocols, etc. These exchanges would increase delays exponentially, coming to a head with the finite transaction times of web sockets and grinding communication to a halt.

If that wasn’t bad enough, lets next consider the challenge of not having an end-to-end connection at all and the possibility of never having one.  Today’s Internet protocols almost all require end-to-end connections to function.  Consider a network with 3 routers that are between the “source” device and a “destination” device. For communications to flow from source to destination, there must be a path between the two devices.  If, for example, the connection between the middle two routers is blocked, packets will not be able to flow through the network.  The Internet was designed to try to overcome such challenges by selecting alternate routes from source to destination when any given link breaks, but those techniques cannot overcome the situation where no alternative links are available.

So why is this important?  Consider the varying rotation and orbits of planets and their respective moons.  In the path from Earth to Mars, for example, there will be times when the Sun sits between the planets and no direct line of sight is available.  A communications array could attempt to redirect the signal through other planets and moons, but the windows of opportunity for direct communication may be few and far between, resulting in long periods of delay or a complete loss of connection.

Beyond the simple inconvenience, there is a greater structural and architectural issue at play.  By its very nature, the internet reaches convergence when all endpoints in the network can communicate with all other points.  In an interplanetary system, where nodes can be abruptly and unexpectedly cut off from one another at any time, this would become impossible.  This creates a paradox by which the current internet’s architecture and the mechanics of interplanetary communication are mutually exclusive.  Put simply, the network cannot converge in space.

Now this is not a new problem.  It has been understood for a long time that traditional Internet protocols would fail for interplanetary communications.

Potential solutions have been implemented in the past to deal with these issues; DTN, or Delay Tolerant Networking (also known sometimes as Disruption Tolerant Networking) is one such attempt to circumvent these issues using redundant networking with store-and-forward queuing. However, DTN as a replacement for the TCP protocol is only a partial solution, and is not dynamically scalable due to its lack of name resolution and routing capabilities. For a single agency monitoring a single spacecraft of known trajectory on a mission where every move has been plotted ahead of time, DTN may be appropriate, but DTN’s lack of a

<Tooltip label='Domain Name Server' to=''>DNS</Tooltip>

means that it will have difficulty routing in more complex environments.  DTN as a protocol also lacks a meaningful security model, and while many suggestions have been made, there are no formal standards for implementing security with DTN. Having been bred initially to address the challenges faced by NASA’s deep space probes, DTN lacks the general-purpose capabilities necessary to make it a viable replacement for today’s internet stack.

WhiteStar Communications, Inc. was founded by pioneers in the DTN ecosystem, who have leveraged their deep understanding of the strengths and weakness of DTN in developing the WhiteStar Network, the first ever Distributed Disruption and Delay Tolerant Network, or D<sup>3</sup>TN.\
\
The WhiteStar Network is an encrypted, hybrid peer-to-peer network, which distributes the burden of networking onto the edge devices, while maintaining a core which helps to facilitate routing for fault tolerance and redundancy.  Like DTN, the WhiteStar Network is inherently a “store and forward” network built upon a messaging orient fabric. Unlike DTN, however, the WhiteStar Network allows its infrastructure to dynamically route information, enabling connections in changing and chaotic environments where many entities may need to communicate in real time.\
 \
Furthermore, D<sup>3</sup>TN allows for the real time assembly of networks, making it infinitely more extensible and more repairable than other inflexible networking protocols.  The WhiteStar NOS can be deployed over existing networks and built into current devices and applications, meaning legacy systems can be easily adapted to use the new D3TN networking architecture.

The WhiteStar Network is also highly secure, allowing for compartmentalized networks to silo themselves from other networks that may be compromised.  No other network allows this level of security in the networking protocol while maintaining flexible extensibility. D<sup>3</sup>TN is not reliant on static routing tables, which rigidly fix the size and shape of other networks.  Naming and routing can be dynamic due to the first-party trust established through the WhiteStar Network’s salutation protocols, enabling devices to connect in an ad hoc manner with extreme levels of security, and conversely, devices can be removed from the network easily if found to be extraneous or malicious.

All combined, this makes D<sup>3</sup>TN the ideal solution for next generation networking, solving not just the problems presented in the hostile environment of space, but also those here on Earth.

The WhiteStar Network is a machine and device agnostic communications solution, capable of running on any modern smartphone or IoT device, and leverages the beyond-Moore’s-Law increase in compute and storage that has revolutionized the mobile and IoT industries in recent years.  By using these billions of user devices to support the network, WhiteStar is capable of delivering a communications infrastructure built on a decentralized ecosystem.

Strong cryptography underpins the entire network, preventing hacking of user data and protecting user’s right of content ownership.  Unlike with a Blockchain network, there are no tokens required to send messages or deploy projects on the WhiteStar Network - instead, WhiteStar is available to create new applications in either of two form factors.  The first is called StarFury and is designed to act as a bridge/adapter for data centers that need to integrate using micro services and REST APIs.  The second is in the form of dedicated applications that have been integrated directly with WhiteStar’s APIs.

WhiteStar is a fully featured solution for the next generation of network infrastructure, capable of being deployed with top-tier cryptographic security as an overlay to quickly and easily adapt existing and integrate new infrastructure, devices and machines into the network.  WhiteStar makes deploying world-class security a snap, with no need for developers to have extensive training on complex security models and networking infrastructure, and it does so at a massively reduced cost over existing legacy Cloud-based and Blockchain networks.

The WhiteStar Network fundamentally shifts the burden of networking, scaling, connectivity, transport, identity management and security into the networking layer from the application.  This eases pain-points felt by all developers deploying applications on legacy Cloud based and Web3 systems, and addresses potential human error where a developer may not be a subject matter expert in any one particular area.  This frees up vital human resources to concentrate on the application layer, saving valuable time and introducing an efficiency unavailable on other platforms.

For example, one powerful benefit of the inherent features of the WhiteStar Network center around identity management.  The current state of the art requires developers who want to manage user’s identities - and any personal identifiable information associated with their identities - in very particular ways to protect user privacy.  However, given the inherent complexity and difficulty in device and application layer identity management, databasing and storage of PID, many developers who lack the skill, time, or are unwilling to properly manage user data leave vulnerabilities open in their applications.  Likewise, centralized repositories of private user information, for example information stored in the Cloud, are juicy targets for would-be hackers seeking to compromise users’ privacy and steal personal information.  This has serious implications when the targets hold immutable personal information like social security numbers, government identification, biometric data, among others, let alone information that could be financially damaging like bank account information, passwords, credit and debit numbers or private keys for cryptocurrencies.

However, by moving the burden of securing this kind of information out of the application and into the network, it efficiently eases the developmental overhead associated with properly securing private user data.  WhiteStar is capable of intelligently securing user data at the end-device level, assured via a deceptively simple series of network semantics, artificial intelligence and cryptography that ensure user data is stored not only within the standards for best practice in user privacy protection, but also adapts to potential security threats as they emerge.  Likewise, WhiteStar’s advanced feature set is fully capable of alerting users and developers to any potential security threats, to allow them to adapt to the changing environment and mitigate network risk before it becomes a problem.  Once a “Bad Actor” is identified, the WhiteStar Network also ensures that actor can no longer interact with users’ applications, further fortifying the Network and its attendant applications against external hostile action.

Because the burden of security is shifted to the Network, all of these benefits are baked in to any application deployed on WhiteStar, allowing developers to concentrate on building great applications without having to worry about securing the network back end.  This illustrates the power of a properly architected platform that can appropriately underpin the next generation of application development.

###### Anyone who has worked in the field of digital security can attest to the difficulty of properly securing a system post-facto.

In fact, properly securing an asset that’s already in the field can take far more work than correctly architecting a solution for that very problem and baking it into the fabric of the product from the start.\
\
Likewise, not every developer is a keen expert in the field of cybersecurity.  Many talented engineers and developers spend their entire careers working purely on deploying applications on the front-end, relying on others to plumb the security models that underpin the project.  Beyond that, building a project to scale often puts it in direct odds to a properly implemented security model, all of which makes large scale, publicly deployed projects easy to attack and exploit.\
\
Additionally, projects built on a centralized infrastructure invariably have a single point of failure; as seen recently, building a critical piece of network-attached infrastructure with a single failure point can lead to catastrophic results, especially when that infrastructure is critical to national security, or continuity of business for a large corporation.\
\
For example, we’ve seen critical infrastructure important to national security shut down by hacks; gas pipelines, power stations, TV and radio stations, ISPs, Cloud infrastructure, all have seen downtime in recent memory due to endemic problems surrounding the underpinnings of the existing Cloud and IoT infrastructure.  Anything connected to the Cloud is vulnerable, it seems - after all, there’s truly no such thing as a Cloud, just someone else’s hard drive.

###### To adequately address the need for properly implemented network security, it needs to be woven into the fabric of every application developed and deployed on the network.  

It needs to be simple and easy to implement - so simple that even a developer who has no background in cybersecurity can deploy applications and have them secured against external threats.  In fact, ideally it would be so simple that there would be no need to even consider network security in the deployment of the project.  This infrastructure should also be fault-tolerant, as decentralized as possible, with no single source of failure in order to prevent hostile attacks, and deal well with poor to no connectivity, or intermittent connectivity over time.  It should also be cheap to deploy and maintain - not just monetarily, but also in man-hour terms.

There have been a few attempts at developing a solution to these issues in the past, the largest of which is the Web3 ecosystem built on Blockchain networks.  These networks of peer to peer computers allow for developers to build and deploy projects via decentralized environments like Ethereum, Cardano and Polkadot.  However, while Blockchain networks solve some of the issues outlined above, they’re not a perfect solution by any means.

For one, these networks are extremely expensive to maintain and deploy, as anyone who has used the Ethereum network can attest.  Executing simple programs - DApps - on the network is extremely expensive due to the competitive bidding process implemented by the network, paid for in a currency generated by solving complex mathematical processes.  This proof of work is not only costly in terms of compute and resource consumption, it’s environmentally unfriendly due to the vast energy waste and requires the constant introduction of new and more powerful hardware to stay current with the capabilities of the network.  In effect, it creates a death spiral for the economies of deploying apps on the Ethereum network, where very quickly the amount of productivity produced by any application deployed on the network is outstripped by the cost of conducting business on the network.

Some networks have more efficient delegation of network traffic and generate the tokens used to enact protocols on the network through a proof of stake mechanism like the Cardano ecosystem, but these networks still suffer from varying degrees of congestion and - perhaps most critically - have a difficult time overcoming issues with concurrency, making certain kinds of apps - especially highly concurrent communications applications - completely unsuitable for deployment on these networks.

Blockchain networks come in many forms, dedicated to many specialized use cases, and there are many advocates of this network or that, however Blockchain networks fundamentally do not address problems around scalability or the economics of the deployment of Dapps, which restricts their use-cases and prevents them from being a true next-generation solution for building a perfect networking architecture.

So if the vaunted Web3 ecosystem isn’t sufficient, what is?  WhiteStar Communications has developed a true next generation networking solution, the WhiteStar Network, which runs as an overlay network to existing infrastructure, and shifts the burden of processing and hosting to the edge of the network rather than the Cloud, and enables cryptographic ownership of content and assets on the network without the need for costly cryptocurrencies.

###### At WhiteStar communications, we use state of the art cryptographic algorithms to protect all information in flight and at rest.

We use well tested, standards-based algorithms that are provided by one of two trusted third parties.  For WhiteStar C++ implementations we use the Crypto++ libraries.  For WhiteStar Java implementations we use libraries supplied by Bouncy Castle.  Both groups are well supported, toughly vetted, and provide optimal implementations of the algorithms that we utilize.

We never use hardware-based cryptography nor keystores in our products.  Hardware is a point in time solution; it will always be breached at some point in time.  We also don’t use the cryptographic libraries provided by our device manufactures.  That is another source of attack outside of our control.

While we do use standards-based cryptography, we don’t use them in the normal “Internet” protocol stack.  Internet based systems typically use a protocol stack that consists of HTTPS over TLS over TCP over IP.  These protocols have many weaknesses that are largely the result of being designed to provide general security across a wide variety of applications and vendors above the network layer (above IP).  This, in turn, was required since the network layer was not designed with security from the beginning but rather security was added to the internet as add on protocols and standards.  WhiteStar’s network and NOS were designed from the beginning with a comprehensive security architecture that does not require application developers or other vendors to know or understand about security principles.  This shifting of what is in the “network layer” vs what is in the “application layer” allows WhiteStar to re-employ the same cryptography, but in a much more capable and homogeneous way.

Within the WhiteStar network we employ a layered approach to security with redundant hardened firewalls, DDoS protection, and separate control and data plane networks.  All deployed servers utilize TPMs that securely boot Red Hat Enterprise Linux (RHEL) running SE Linux with ultra-high trust certificates.  These servers are maintained in hardened US Based data centers which are maintained by a staff of former US military personnel.

###### Protection of Intellectual Property is another tool in the WhiteStar security toolbox.

Having patents on key concepts and ideas provides legal and political recourse should an attacker attempt to exploit the network using various techniques such as “back” or “reverse” engineering the system or even through state or industrial espionage.

WhiteStar has strategically planned its’ patent portfolio to protect its customers for a specific class of attackers that would seek to subvert that intellectual property as well as to provide maximum value to the company and its’ shareholders and to protect its’ competitive advantage in a world of evolving technology.       

In furtherance of our security culture, WhiteStar goes to great lengths to practice secure communication, even when discussing our Intellectual Property (IP), by requiring Non-Disclosure Agreements (NDAs) for all investors, shareholders, and employees, as well as, when appropriate, for engagements with various vendors or prospective partners.  WhiteStar does not use contractors, does all development in the US and only hires US Citizens that have had or can get a security clearance.  Each employee who joins WhiteStar fully understands their obligation to protect our IP and how that protection helps to facilitate protection of our customers' information as well.

Every employee is required to sign an intellectual property assignment agreement ensuring all inventions and work product created during their employment is assigned to WhiteStar Communications to be held on behalf of our customers.  In recognition of the value of WhiteStar’s IP, we have implemented a comprehensive employee incentive program to encourage employees to innovate and participate in the discovery and development of these new technologies.

<Center>WhiteStar has an extensive patent portfolio of US and International Patents.  Key security technologies within the WhiteStar patent portfolio include, but not limited to:</Center>

<ipaccordion>\
{"title": "Systems and Methods of Salutation Protocol To Communicate Using a Private Overlay Peer to Peer Network - USP 11,265,325", "text": "Salutation is a special protocol used by a pair of WhiteStar nodes to form a Cohort.  Once a Cohort is formed, then nodes can securely communicate with each other using a variety of peer to peer or hybrid peer to peer protocols.", "id": "USP 11,265,325"}\
{"title": "Systems and Methods of Securing Digital Conversations for Its Life Cycle at Source, During Transit and at Destination - USP 11,343,098", "text": "One challenge of securing data at rest is knowing how long the data should be secured.  As the volume of information being secured grows then the challenge of keeping that information secured grows.  This patent covers how we apply life cycle policies to data at rest to reduce the volume of data that needs to be protected.", "id": "USP 11,343,098"}\
{"title": "Systems and Methods of Collaborative Application on a Private Network - USP 11,546,170", "text": "When information is transferred (in flight) from one node within a conversation to one or more other nodes, then that information gets encrypted for each cohort (pair) of nodes using the unique pairing of keys derived from that cohort.  No group keys are ever used to transfer information from one node to one or more other nodes. ", "id": "USP 11,546,170"}\
{"title": "Systems and Methods of Enforcing Communications Semantics on a Private Network - USP 11,463,418", "text": "This patent covers the semantics of how WhiteStar forms and protects information flows between nodes.", "id": "USP 11,463,418"}\
{"title": "Systems and Methods of Gesture Triggered Automatic Erasure on a Private Network - USP 11,768,951", "text": "A system that directs the Sentinel AI agent to coordinate with the Guardian AI Agent to cryptographically remove sensitive information from every node that has a copy of that information within the WhiteStar network.", "id": "USP 11,768,951"}\
{"title": "Systems and Methods of Distributed Backup and Recovery on a Private Network - USP 11,068,195 B2", "text": "Provides a distributed and secure means by which information can be securely backed up and recovered in a peer-to-peer network.  Information is protected both in flight and at rest.", "id": "USP 11,068,195 B2"}\
{"title": "Identity Management System Establishing Two-Way Trusted Relationships in a Secure Peer-to-Peer Data Network - USP 12,058,243", "text": "Distributed means for creating a secure identity for nodes within the WhiteStar network.", "id": "USP 12,058,243"}\
{"title": "Crypto-Signed Switching Between Two-Way Trusted Network Devices in a Secure Peer-to-Peer Data Network - USP 11,924,177 B2", "text": "A means through which hybrid peer to peer sessions can be used to send secure packets in flight.  Packets in flight can be securely switched across multiple hops to flow from a source node to a destination node via some number of intermediate nodes while maintaining end to end encryption.", "id": "USP 11,924,177 B2"}\
{"title": "Anti-Replay Protection Based on Hashing Encrypted Temporal Key in a Secure Peer-to-Peer Data Network - USP 12,126,728", "text": "A means by which the Sentinel AI agent can detect a replay attack in the WhiteStar network and mitigate that condition through coordinating from a menu of actions between the Guardian and Navigator AI agents.", "id": "USP 12,126,728"}\
{"title": "Distributed Security in a Secure Peer-to-Peer Data Network Based on Real-Time Guardian Protection of Network Devices - USP 12,081,558", "text": "The Guardian is an AI agent that is used to secure data in flight and at rest within the WhiteStar network.", "id": "USP 12,081,558"}\
{"title": "Distributed Security in a Secure Peer-to-Peer Data Network Based on Real-Time Sentinel Protection of Network Devices - USP 11,924,229", "text": "The Sentinel AI agent can detect threats in real time within the WhiteStar network and either mitigating those threats autonomically or coordinating remediation actions with other agents or the end user.", "id": "USP 11,924,229"}\
{"title": "Distributed Security in a Secure Peer-to-Peer Data Network Based on Real-Time Navigator Protection of Network Devices - USP 11,949,717", "text": "The Navigator AI agent coordinates with the Sentinel and Guardian AI agents in order to secure information in flight within the WhiteStar network by assessing the risk of utilizing any given network resource for communications.", "id": "USP 11,949,717"}\
{"title": "Directory Server Providing Tag Enforcement and Network Entity Attraction in a Secure Peer-to-Peer Data Network - USP 12,113,785", "text": "We use tags to assure user rights over their content and to provide authoritative identity when associated with first class objects within the WhiteStar network.", "id": "USP 12,113,785"}\
{"title": "Localized Machine Learning of User Behaviors in Network Operating System for Enhanced Secure Services in Secure Data Network - USP 12,267,325", "text": "How we protect users from being data mined by third parties while still allowing meta data to be used exclusively by the user’s own devices for the user's own benefit.", "id": "USP 12,267,325"}\
{"title": "Community Server for Secure Hosting of Community Forums via Network Operating System in Secure Data Network - USP 11,582,241", "text": "", "id": "USP 11,582,241"}\
{"title": "Secure Peer-to-Peer Based Communication Sessions via Network Operating System in Secure Data Network - USP 11,792,186", "text": "", "id": "USP 11,792,186"}\
{"title": "Crypto Tunnelling Between Two-Way Trusted Network Devices in a Secure Peer-to-Peer Data Network - USP 11,784,813", "text": "How we securely tunnel information in flight between two nodes via intermediate nodes without having a direct peer to peer relationship. ", "id": "USP 11,784,813"}\
{"title": "Password Concatenation for Secure Command Execution in a Secure Network Device - USP 12,058,122", "text": "Concatenation of security related commands to be executed during login processing on a WhiteStar node.", "id": "USP 12,058,122"}\
{"title": "Secure Device Access Recovery Based on Validating Encrypted Target Password From Secure Recovery Container in Trusted Recovery Device - USP 11,870,899", "text": "WhiteStar does not maintain a database of user passwords.  This patent describes how we enabled customers to recover their own passwords using a secure distributed recovery mechanism between two nodes that they trust. ", "id": "USP 11,870,899"}\
{"title": "Establishing and Maintaining Trusted Relationship Between Secure Network Devices in Secure Peer-to-Peer Data Network Based on Obtaining Secure Device Identity Containers - USP 11,582,201", "text": "How we update and maintain security trust relationships between nodes over time.", "id": "USP 11,582,201"}\
{"title": "Secure Keyboard Resource Limiting Access of User Input to Destination Resource Requesting the User Input - USP 12,088,590", "text": "How we secure keystrokes from the keyboard from being intercepted and by unauthorized applications.", "id": "USP 12,088,590"}\
{"title": "Coherent Pictograph Oganizer Based on Structuring Pattern Markers for Hierarchal Pictograph Presentation - USP 11,841,898", "text": "", "id": "USP 11,841,898"}\
{"title": "Dynamic Secure Keyboard Resource Obtaining Interface Definitions for Secure Ad-hoc Control of a Target Device in a Secure Peer-to-Peer Data Network - USP 11,811,755", "text": "", "id": "USP 11,811,755"}\
{"title": "Autonomic Distribution of Hyperlinked Hypercontent in a Secure Peer-to-Peer Data Network - USP 12,069,032", "text": "", "id": "USP 12,069,032"}\
{"title": "Secure Autonomic Recovery From Unusable Data Structure via a Trusted Device in a Secure Peer-to-Peer Data Network", "text": "How the Sentinel and Guardian AI agents work together to recover encrypted information at rest that has been tampered with.", "id": "17/509,757"}\
{"title": "Secure Assistance for Asynchronous Task Completion by Unavailable Endpoint Device upon Restored Availability in a Secure Peer-to-Peer Data Network - USP 12,010,245", "text": "", "id": "USP 12,010,245"}\
{"title": "Secure Streaming Media Based on Updating Hypercontent in a Secure Peer-to-Peer Data Network - USP 12,052,266", "text": "", "id": "USP 12,052,266"}\
{"title": "Secure Ad-hoc Deployment of IoT Devices in a Secure Peer-to-Peer Data Network - USP 11,848,763", "text": "", "id": "USP 11,848,763"}\
{"title": "Mitigating Against a Persistent Consistent Threat in a Network Device Based on Reducing Temporal Surface Area - USP 11,880,496", "text": "", "id": "USP 11,880,496"}\
{"title": "Secure Peer-to-Peer Based Communication Sessions via Network Operating System in Secure Data Network - USP 12,063,213", "text": "", "id": "USP 12,063,213"}\
{"title": "Dynamic Secure Keyboard Resource Obtaining Interface Definitions for Secure Ad-hoc Control of a Target Device in a Secure Peer-to-Peer Data Network - USP 12,003,504", "text": "", "id": "USP 12,003,504"}\
{"title": "Crypto Tunnelling Between Two-Way Trusted Network Devices in a Secure Peer-to-Peer Data Network - USP 12,058,258", "text": "", "id": "USP 12,058,258"}\
{"title": "Crypto-Signed Switching Between Two-Way Trusted Network Devices in a Secure Peer-to-Peer Data Network - USP 12,126,602", "text": "", "id": "USP 12,126,602"}\
{"title": "Device-Specific Selection Between Peer-to-Peer Connections and Core-Based Hybrid Peer-to-Peer Connections in a Secure Data Network - USP 12,160,741", "text": "", "id": "USP 12,160,741"}\
</ipaccordion>

Today’s Internet was conceived during the cold war as a way for research scientists to communicate. At that time, security and scalability were not primary design factors as only a few trusted institutions were interconnected via secure telephone lines. Instead, the focus was on durability, mitigation of congestion, reliable transport and interoperability.  The Internet architecture is loosely based on a modified OSI stack as shown below:

![Network Diagram](/img/group-92.png)

In today’s Internet, the datalink and physical layers are mostly

<Tooltip label='IEEE 802.x defines a variety of Ethernet protocols that run over top of various media layers.' to=''>“Ethernet”</Tooltip>

based, whether that be over wires, coaxial cable, wireless or fiber.  The network layer is the “Internet Protocol” or IP layer and is either based on IP version 4 or the more recent IP version 6.  As can be seen in the above illustration, it is the IP layer that allows packets to flow from any host A to any other host B via any number of intermediary devices (what can be called a network of devices — or simply the network layer.)\
\
Two protocols dominate the next layer of the Internet,

<Tooltip label='RFC793 Transmission Control Protocol' to=''>TCP</Tooltip>

and

<Tooltip label='RFC768 User Datagram Protocol' to=''>UDP</Tooltip>

, both of which run over the IP layer and thus are generally referred to as TCP/IP or UDP/IP.  TCP, or Transmission Control Protocol is the dominant protocol within the Internet and provides for “reliable” and “orderly” communications between hosts.  Above TCP, the dominant application protocol is

<Tooltip label='RFC2616 and RFC2068 Hypertext Transfer Protocol' to=''>HTTP</Tooltip>

, or the Hyper Text Transport Protocol, that allows clients and servers to exchange multi-media documents.\
\
*As is illustrated above, within the Internet architecture, security has always been an afterthought.*  There are various

<Tooltip label='IEEE 802.1AExxx MACSec and others' to=''>protocols and standards</Tooltip>

that allow for securing the “Ethernet” layer on a hop-by-hop basis between nodes on the “network”, however with this approach, packets are decrypted and then re-encrypted at each node.

###### Like Ethernet, TCP has a secure counterpart.

Today’s current version is called

<Tooltip label='RFC5246, RFC8446, RFC6066, RFC4492 Transport Layer Security' to=''>TLS</Tooltip>

, or Transport Layer Security, which rides on top of TCP and provides encryption services generally based on public/private key pairs. 

<Tooltip label='RFC2818 HTTP over TLS' to=''>HTTPS</Tooltip>

(or secure HTTP) negotiates for a secure TLS link to be used to transport data between hosts in a seemingly secure manner.  However, the trust model for this is generally broken in that the authentication of who is host A and who is host B is generally only one way.  In other words, if you use a browser to have a HTTPS session with your bank, the HTTPS/TLS session from your browser to your bank only ensures that your bank is who it says it is but not that you are who you say you are.  Because of this, the “application layer” must authenticate the “bank user”, generally “Logging Into” the bank account.

Because of the

<Tooltip label='HTTPS defines bi-directional authentication, but it is rarely, if ever used' to=''>lack of bi-directional authentication</Tooltip>

of HTTPS sessions, there is an opportunity for an intermediate node, called a HTTPS or TLS proxy to be a “man-in-the-middle” between the client (browser) and the server (the bank.). The proxy node can “pretend” to be the bank and therefore decrypt all the packets flowing through it and then re-encrypt, “pretending” to be the browser.  This “feature” allows enterprises, for example, to enforce corporate policies and detect exfiltration of important information.

Finally, HTTPS/TLS only secures data in flight.  Once your “personal information” reaches your bank or internet service provider, the information you sent gets decrypted and then stored somewhere, possibly in many places and often not encrypted.

In addition to a lack of intrinsic security, the Internet and the services that have been built upon it have massive scaling problems.  The Internet is a “single network” in which billions of hosts are attached.  As more and more of those hosts are mobile (such is the case with cell phones), then keeping track of all the hosts and their current IP addresses within the network becomes an increasing challenge.  Additionally, the Internet allows for any host on the “network” to route packets to any other host.  The ability to do this is considered to be the point in which the network has converged.

While this is a nice feature, it also is a major security issue in that it allows any host to attack any other host in what is called a DoS (denial of service) or worse a DDoS (distributed denial of service) attack.  These types of attacks seek to make a host’s computer or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to the Internet.

Finally, there’s the matter of identity vs network address.  When the Internet was first developed, IP address were fixed.  Address blocks were sub-divided by companies or organizations that needed to attach hosts to the Internet.  Organizations would sub-divide, aka. sub-net, their block addresses into smaller blocks and then physically assign those blocks to floors of buildings.  Addresses where then wired up to ethernet jacks in cubicles and offices.  With this arrangement, one could imply that a host at a given IP address was a given person as a person was assigned that office space.  Additionally, a given IP address could be inferred to belong to a given organization and even imply its location.

Today, none of that is true.  Addresses are dynamically assigned; sub-networks are reused using NAT/PAT and people roam across networks and addresses with mobile devices.  All of this has caused significant security and scaling issues that have been band-aided over the years.

###### The WhiteStar Network and the WhiteStar Network Operating System have been built to address all these shortcomings of the current Internet stack.

\
WhiteStar has been built from the ground up to be both always secure and scalable and to have proper addressing semantics. While the Internet is a single network with billions of hosts in it, WhiteStar creates billions of small networks, each with potentially hundreds of hosts per network.  This can be seen as billions of clusters of interconnected hosts as shown below:

![Diagram of many interconnected clusters of nodes](/img/group-101.png)

The WhiteStar Network does not attempt to automatically allow the inter-connection of every host to every other host and as such is immune to all forms of DoS and DDoS attacks as well as their application layer equivalent known as SPAM, Phishing, Spear Phishing, etc.  The WhiteStar Network accomplishes this through several technologies, which require its subscribers (people and things) to opt-into every relationship that they join.

###### WhiteStar builds “trust” from the ground up with a distributed first party trust system known as Salutation and uses that foundation to both secure information in flight between hosts, and when at rest when it arrives at a host.

Essentially, trust and indeed the entire WhiteStar Network are formed from the edge of the network, without any centralized services.

In addition to forming trusted relationships as a foundational technology, WhiteStar also includes replacement protocols for the classic HTTPS/TLS/TCP/IP stack commonly used by Internet Cloud/Server/Client services today.  These protocols have been carefully crafted to ensure proper manners and behaviors and controls by its end users.

In essence, WhiteStar’s NOS enables and enforces manners and etiquette that have been present in human culture since man first learned to communicate.  WhiteStar addresses and prevents the misuse and misappropriation of content, photographs, video, data and words by using integrated social semantics.  With traditional social media publishers that were built on current Internet protocols, it is easy to abuse the free access to others’ data which has become a problem for humanity.  WhiteStar Communications sought to create a network that is intrinsically secure and safe to use.  Those who are sensitive to these issues of privacy and data integrity will appreciate the care with which WhiteStar’s core mission philosophy is defused into the fabric of the WhiteStar network.

We are now knee-deep in the era of the Deep-fake; unscrupulous individuals can gain access to others’ data and create fake content in order to blackmail, extort or damage others.  This level of unprecedented identity theft can be used to create fake images, videos, audio, social media posts, etc., and can easily destroy a person’s livelihood and social standing.  As a culture, we should be gravely concerned with protecting the integrity of social media users, and the next generation, as they grow up in this environment.  WhiteStar’s infrastructure and apps like SOCIETY help to ensure that content is not misused by nefarious entities.

With the WhiteStar NOS, relationships are formed and maintained by the peered subscribers within the network itself rather than any application based on the WhiteStar Network.  Only a trusted party can contact another subscriber; essentially subscribers must opt-into a relationship which we call a Cohort in order to have contact.  The WhiteStar Network also understands the concept of out casting, which allows subscribers to permanently block other untrusted subscribers or their content by tagging them as an outcast.  The judgement of who is trusted, or untrusted, is at the sole discretion of the individual subscriber, and not controlled by the network.

In order to better understand the unsecure vulnerabilities of the traditional social media/internet versus the robust security of the WhiteStar Network, consider the illustrations on the left.

The top figure illustrates the current ultra-vulnerable and utterly unsecurable structure of today’s traditional social media/Internet where a user’s data is not owned nor controlled by the subscriber.  In this structure the content is all owned by the Service providers the moment the subscriber posts their content.  This content is then stored on servers somewhere, possibly in many locations around the world, and is subject to whatever laws those foreign entities impose, which often include those governments having full access to the data.  Your content can be data mined by companies wishing to profit from your content.

Additionally, there are immeasurable points of vulnerability that can be easily hacked into by bad actors anywhere around the world.  Even if the ISPs wanted to address this issue, their structure does not allow for it.  Further, they are but one corrupt employee away from a major data leak from an “inside job”.

By contrast, all content in the WhiteStar Network is always owned and controlled by the originator of the content and all content is always protected by WhiteStar and never stored on a server; we are cloudless by design.  Your content is cryptographically secured by WhiteStar both at rest (in an encrypted vault on your device, as well as in an encrypted vault on the device of whomever you allow to view your content) in addition to being encrypted in flight between the owner and with whomever they wish to share their content.  Your content is only stored on the devices with whom you shared it and is always subject to

<Tooltip label='Zeroization is a process by which WhiteStar will permanently and cryptographically remove all content of a user from every device that content is stored within.' to=''>Zeroization</Tooltip>

by you if you wish to remove it from the devices of others.  Moreover, and by design, WhiteStar’s cryptography algorithm is so secure that not even our employees can break it even if we explain to them exactly how it works.

###### The WhiteStar NOS also features a fully integrated password authentication system.

Traditional password control systems typically rely on patterns (such as requiring some combination of upper- and lower-case letters along with a special character or a number along with a minimal number of total characters.)  Additionally, it is normal in enterprise settings to require passwords to be changed on a fixed time schedule.  Both approaches have serious drawbacks.  Requiring certain patterns within a password don’t necessarily give surety as to the strength of a password.  Similarly, changing passwords on a fixed schedule is only a band-aid on the larger problem of not picking strong passwords to start with.  This leads to further problems as changing and rolling out a new password, particularly in an enterprise setting, is filled with error and often causes issues that IT must then be engaged to correct.

To address these sorts of issues, WhiteStar has developed a novel Autonomic Password Management System.  Simply enter any password combination of alphanumeric and special characters and WhiteStar’s system shows you how long that password will be safe to use based on the present day commonly available hacking techniques combined with a temporally scaling model of compute power to estimate the time it would take a hacker to gain access to a subscriber’s account based on the actual password chosen by that subscriber.  With WhiteStar, Passwords and their enforcement is now a part of the Network itself.

WhiteStar continuously re-evaluates each user’s chosen password and should new techniques, algorithms or unpredicted increases in compute power come along, then WhiteStar will revise the time that remains before the subscriber’s password must change.

As part of the WhiteStar security package, the WhiteStar Network Operating System disables screen capture and send ability so that content cannot be taken and distributed without a user’s permission, and there is no provision to download content without the express consent of the user. Where possible, all WhiteStar applications disable the screen capturing of content.

###### The WhiteStar Network Operating System utilizes a variety of AI agents.

Security is orchestrated in novel and powerful ways through a synergistic interaction of three such agents: the Guardian, the Sentinel and the Navigator.  The Guardian is what most people think of when they think about security.  The Guardian protects data in flight and at rest using advanced first party trust and proven cryptographic algorithms.

The Guardian protects passwords and it’s the Guardian that estimates their hack times.  The Guardian provides full attestation of all parties, devices and messages.  The Guardian provides protection against advanced threats and us strategies to avoid replay attacks.  The Guardian attempts to block content exfiltration through screen captures, the clip board and other means.

By contrast, the Sentinel agent monitors for cyber threats and attacks and attempts to detect them in real time.  The Sentinel assists subscribers in connecting and revoking relationships to manage bad actors.  The Sentinel allows subscribers to outcast relationships, conversations and message.  The Sentinel notifies subscribers when hacking and other bad behaviors are detected.  Finally, it is the Sentinel that intelligently provides an array of threat mitigation strategies including: management of backups, zeroization and revoking/out casting relationships.

Finally, the Navigator works with both the Guardian and Sentinel to orchestrate navigation policies that in turn decide what networks and types of network connections should be used to carry out connections between devices.  The Navigator considers threats detected by the Sentinel as well as network availability, power level, federations, and likelihood estimates of the need to converse as it “navigates” to the safest ways for parties to communicate.

###### WhiteStar believes that security is a journey, not a destination.

No matter how hard we try, we will never reach a place where our systems and services are “secure”.  Therefore we must always be moving forward, pushing the bar higher and higher.  To facilitate this, we have carefully architected every aspect of our system for evolution.

At WhiteStar, we operate on the principal that no matter how good of a job we do today to secure something, someone in the world will eventually find a way around currently accepted algorithms and practices.  While that might sound hopeless, there are specific practices that we engage in to manage this reality.

###### One of the most important tools we use is planning for two steps of evolution ahead of current technologies, and being prepared to immediately deploy enhanced capabilities within our products if a breach or weakness is detected.

To illustrate this point, consider something like encryption key size.  Currently we ship our product using 256 bit AES encryption keys.  We know that this is considered unbreakable today.  However, we know that eventually it will be broken.  Applying our two-step process means that we need to plan for what we do for the next key size as well as cipher algorithm.  And not just the next one, but the one after that. In doing so, we carefully architect our current system, the one shipping today, for everything we would need to make those two steps forward.  Furthermore, we have developed the next step and have it on the shelf, ready to go.  When we take that next step, we then plan out another so that we continuously have two steps ahead planned and architected.

One might wonder why not just deploy the bleeding edge best solution we have today?  The answer is a simple concept.  Once you are hacked, and you will eventually be no matter how strong of protection you employ, there is a window of time from when you have been breached until when you can fix or replace the system that has failed.  During that time your system is vulnerable to exploitation.  We want to make that time window as small as possible.  One way to do that is to be able to immediately deploy your next step, your planned replacement, closing the window almost instantaneously.  

The ability to immediate mitigate any breach not only protects your systems, but it has a profound physiological effect on those that would seek to attack your system.  You see it is quite difficult and time consuming to compromise a system that has been well architected.  Great time, energy and cost goes into such attacks.  Many years of dedicated effort might be necessary to breach a system.  If after all that effort, the system immediately “changes” and your exploit is no longer useful, then the “reward” for having spent all that effort is practically nothing.  This, quite frankly, is demoralizing to black hats and is exactly the benefit that having two steps ahead planned and architected provides.

The National Institute of Standards and Technology (NIST) has recently been given the task of defining “Critical Software” and best practices for protecting it.  NIST has published NIST SP 800-161 which is a draft working copy covering these topics.  At WhiteStar Communications, we are committed to doing our part of protecting “Critical Software” as defined by NIST.

By NIST Standards, WhiteStar is to be considered Critical Software and as such we have decided to follow the recommended best practices for Mitigating the Risk of Software Vulnerabilities by adopting the secure software development framework (SSDF) outlined by NIST.

<p class="lead">In addition to the NIST SSD framework, we have implemented a set of general principals to secure our software supply chain.</p>

The first practice is to never trust hardware to do cryptography.  Hardware is supplied by third party companies through a complex set of relationships, design houses and foundries and we believe it’s too hard to adequately secure for the short term and probably impossible for the long term.

WhiteStar Communications has also decided to dramatically limit our open-source exposure.  We carefully groom and select open-source projects to draw from.  Once selected, a snapshot copy is taken and held within our own internal repository from which we build our projects.  Taking this step eliminates the possibility of a bad actor inserting software into our products using the ecosystem of public repositories.

We deliberately stay away from “free” open source development tools.  All our tools are commercial products that we have carefully screened for bad actors.  By executing a license agreement with the tool provider we have legal recourse should a bad actor attempt to attack our supply chain through their tool.

Additionally, WhiteStar Communications owns and operates our own bare-metal servers, protected in secure data centers.  We don’t use public or shared servers for any of our development, tools, test or production systems.  We have carefully selected equipment, tools and best practices so that our develop and deployment servers are fully protected.

We utilize a set of general principals to further secure our supply chain.  These include employing a layered defense with hardware fire walls, using geographical firewall defense, DDoS protection, secondary software fire walls, secure boot, secure operating systems and finally segmented control and data plane networks.

The term “Surface Area” is often used in discussing security to illustrate how many ways a secure system can be attacked, and if attacked, how big of a prize, in the form of information, could some would be attacker acquire from the compromised system.  In general, smaller surface area is better.  The WhiteStar Network has been purposefully designed to present the smallest possible useful surface area, thereby making the challenge of hacking it as large as possible while at the same time keeping the prize for having hacked it as small as possible.

The WhiteStar network achieves minimal surface area through a technology that we call Cohorts.  A cohort can be thought of as a unique pair of devices.  To facilitate the formation of Cohorts, the WhiteStar network operates as a hybrid peer-to-peer network, without the need for a Cloud or any servers.  A single pair Cohort is a set of two distinct network endpoint devices with trusted interlinks between them.  Cohorts are established by exchanging unique pairwise cryptographic keys in a specialized Salutation Protocol using first party trust. 

Additional endpoints can ‘opt-in’ to join a Cohort by forming first party relationships with each and every other endpoint within the Cohort.  This creates a mesh network of first-party trust between each set of individual endpoint participants within the Cohort.  Once connected, endpoints within a Cohort share data with all other Cohort members by utilizing the unique key pairs.

Each Cohort is compartmentalized which prevents non-trusted devices from gaining access to the information exchanged within the Cohort unless they are deliberately given access.  Extrapolating the Cohort Architecture onto a larger social graph, this technology allows Cohorts to interconnect, forming larger meshed connections of first party trusted devices with guaranteed security.

###### The unique advantage of the WhiteStar network is that the risk surface area is reduced to one.

What this means is that for two devices to communicate with each other only one other device is involved – the other party.  Think of this as the ultimate form of whitelisting, where each party is deliberately whitelisted into a first party trusted relationship with each counter party.  In the WhiteStar network there is no such thing as “group cryptography” with keys shared among a larger group of endpoints, nor is there a trusted third party used to establish trust relationships in an indirect way. With networks that use group cryptography or group keys, the risk surface area increases proportional to the number of devices added to the network.  So if there are seven devices sharing a group key, then compromising any of the seven would gain an attacker access to all seven.  We say therefore that the surface area is seven.  As the number of devices sharing the same key grows, surface area grows one for one with each new device.

At the same time, as the surface area grows the prize grows as well.  Compromising one of any of the seven devices means that an attacker can access information on seven devices.

In contrast, WhiteStar’s Cohort architecture produces an absolute minimum, finite and constant risk profile of one, even as the number of connected endpoints increase.  Due to the compartmentalized nature of each of the Cohorts, it easy to see that the prize for compromising a single device is at most that an attacker could access information from a pair of devices. 

The security of the Cohort architecture is in direct contrast to the Internet itself, which always has full connectivity between all devices.  In effect, the Internet whitelists every device into the same network.  This connectivity model makes it highly susceptible to tampering as it assumes any device can be trusted to communicate to any other device on the network.  Since the network doesn’t understand concepts like trust, identity or authentication, these topics are typically implemented above the network layer and in many cases at the application layer itself.  With respect to risk profiles, the typical internet model presents unlimited risk due to the unlimited nature of device exposure.

This emphasis on security flows right through how we design and develop our products, with a base tenant being security is implemented from the beginning, not as an afterthought.  \
\
Philosophically, we believe that any system is only as secure as its’ weakest link. To that end WhiteStar employs only US citizens who have previously held, or could obtain if needed, a security clearance.  WhiteStar subjects each new employee to a comprehensive background check to ensure the trustworthiness of our workforce.  \
\
Furthermore WhiteStar never has, and never will, outsource our engineering work.  All development is undertaken in-house at our offices in Research Triangle Park, North Carolina while also maintaining a satellite office in Marietta, Georgia.  \
\
WhiteStar is funded entirely by qualified private investors avoiding the traditional venture capital firms whose money may come from international investors.  Our investors are vetted to ensure they, too, are US Citizens and align with our mission of bringing greater digital liberty to the world.  In order to avoid any unwanted influence, or questioning of who has access to our intellectual property, it is our policy that we will not accept investment from foreign entities.\
\
WhiteStar prides itself on continuous education of our employees and the development of strong habits to maintain digital security.  Employees are routinely briefed on emerging cyber threats in the world, raising awareness of potential attack vectors on WhiteStar products.  The team also dedicates time engaging in rigorous philosophical discussions on how to best maintain user data privacy, making sure that all actions undertaken by the company are in accordance with WhiteStar’s founding principles.  \
\
Knowledge of current and future threats is infused into our development process, ensuring that all products released robustly react to today’s threat matrix.  Internally, practicing what we want our customers to realize, WhiteStar maintains secure communication channels through our SOCIETY app in order to protect the integrity of our internal communications.\
\
Finally, WhiteStar tracks our competitors for the purpose of understanding the current state-of-the-art, evolving vulnerabilities, and to have a thorough understanding of the capabilities of both our peers and the “Black Hats” who seek to attack them.  We also maintain a hands-on testbed of competitive products and technologies in order to gain a more thorough understanding of other entities in this space.   By analyzing the information obtained, WhiteStar learns from the mistakes and successes of others, allowing us to more accurately address emerging threats in our products, and understand the ways in which the company or its products can be attacked.