About us
FAQs
Frequently Asked Questions
The vision for our tech is to make it as easy as possible for developers and customers to implement solutions that are private and secure. We use cryptography and a novel platform approach to accomplish this which is further explained in the Q&A below.
Did we miss something? Email us at support@atsign.com. Thanks!
atSigns
What is an atSign?
An atSign (e.g. @alice) is simply a resolvable address, kind of like an email address. Anything can have an atSign; a person, organization, or thing (IoT device, gateway, router, etc.). Even a cow or a tree can have an atSign!
What is an atSign used for?
An atSign is used to protect and securely exchange information with other atSigns without any chance of surveillance, impersonation, or theft of the information by anyone. That secure information exchange can be a pure data exchange, or it can be used to provoke an action in the receiving system (for example, SSH No Ports).
How is the information exchange between atSigns secured?
The mechanism for securing communication between atSigns is to encrypt the information at origin using cryptographic keys that are cut and kept on these edge devices (sender and recipient). Thus, the only points where the data is able to be decrypted and viewed in the clear are on the sender and recipient edge devices. In other words, the data is uniquely encrypted by the sender for the recipient and nobody else (including Atsign) is able to access it because they never have access to the cryptographic keys.
How is data transmitted?
Socket connections to all atServers are initiated by looking up the DNS address and port number in the atDirectory, then a direct connection is made to the atServer. Newly created data is encrypted with the symmetric encryption key and stored on the atServer. If the data is shared with another atSign, it is encrypted using a separate symmetric key for that atSign. The symmetric key used to encrypt the data is then encrypted using the asymmetric public key of the recipient’s atSign.
Let’s say that Alice (@alice) wants to share data with Bob (@bob). @alice’s device creates a new AES encryption key and encrypts the data with it, her device stores it on her atServer. In addition, her device also stores a copy of the AES encryption key which is encrypted for @bob using @bob’s RSA public key. @alice’s atServer then lets @bob’s atServer know that there is data to receive. @bob’s device retrieves the data by first decrypting the AES encryption key using @bob’s RSA private key, then decrypting the data itself using the AES key. @bob now has access to the data.
What characters can be used to form an atSign?
atSigns can be made of any combination of UTF-7 characters up to 55 characters in length to be used that are not already owned by someone else. This provides for an enormous name space of 10^224 atSigns.
Certain combinations of characters may be unavailable or restricted including trademarked names, already registered atSigns, etc.
atServers
What is an atServer?
An atServer is both a private datastore for storing encrypted data owned by an atSign and a rendezvous point for information exchange. An atServer is responsible for the delivery of encrypted information to other atServers, from which the owners of those atSigns can then retrieve the data. What is important to know is that the atServer stores only encrypted information and never has access to the cryptographic keys.
What functions does an atServer perform?
An atServer provides the following functionality:
- Cryptographic authentication of client devices
- Cryptographic authentication of other atServers.
- Persistence of encrypted data on behalf of the controlling atSign.
- Caching of data shared by others with the controlling atSign.
- Notification of data change events to clients (edge devices) and other atServers to facilitate delivery of information shared with them.
- Synchronization of data with multiple clients (edge devices).
- TLS wire encryption from clients to atServers using SSL certificates.
- Mutually authenticated TLS 1.2/1.3 wire encryption between atServers using SSL certificates.
What does an atServer consist of?
An atServer is a very small dockerized service that can be deployed basically anywhere. An atServer requires a means to persist data, and requires publicly addressable network connectivity. (The atServer’s DNS address and port number is stored in the atDirectory service.) This provides an isolated instance of the service for each atSign.
This distributed architecture ensures that there is no centralized service mixing one atSign’s data with any other atSign’s data. This is unlike traditional centralized web services that are multi-tenant and mix together data from a number of sources, making them a target for hackers to get lots of data at one time. Additionally, as all private data is encrypted with keys that it does not have access to, even if a bad actor accesses an atServer, they would have no way of decrypting the data.
How does authentication work with an atServer?
The very first authentication to an atServer makes use of a shared secret, also known as a cram key. A public key pair using RSA2048 or ECC is then created to be used for subsequent authentication via a public key authentication mechanism (PKAM).
How does authentication work with an atServer?
Each atServer contains information for a single data owner, making it an inefficient target for hackers. If someone is able to locate an atServer location and gain access to its datastore (which is highly unlikely), they would find that all private data that it holds is encrypted, and that they have no means of getting access to the cryptographic keys. This is why we can say it is “provably true” that the data is protected.
Other methods of data protection rely on policies and procedures to safeguard data. These rules are not effective enough, as it is certainly possible for the wrong person with the right access to ignore them. Large servers that hold data from a very large number of data owners are an appealing target for hackers.
Where are atServers hosted?
Running servers reliably and keeping SSL certificates up to date is not easy. We provide two hosting options:
- Atsign-hosted atServers
- All atServers are run by Atsign on the cloud where we have heavily automated deployment and maintenance. It is important to know that we are not able to see any private data because it is encrypted with keys that we do not ever have access to.
- Privately hosted atServers
- atServers can also be run by anyone on a variety of platforms ranging from a Raspberry Pi to a cloud service like GCP or AWS, or even on premises. In the future, we expect and encourage other providers to run atServers anywhere.
If someone hacks into an atServer, what will they find?
The DNS location of an atServer can only be derived from the atDirectory server which requires knowledge of the atSign it serves. All data stored by an atServer is encrypted at rest as a first line of defense. The atServer is able to access its data store which contains a combination of public and private data. It is easy for anyone to scan and access public data as that is the intent of sharing it publicly. Only the data owner and intended recipients will ever be able to access their private data which is encrypted specifically for those recipients. Data that is shared with others is always encrypted in such a manner that only the data owner and the intended recipient can ever access the data.
How big is an atServer, and how much can it store?
The atServer can store as much data as its underlying storage system allows, and of course an atServer requires RAM and CPU to function. For those atServers which Atsign operates, our default configuration is to allocate 50MB of memory to the docker container, which is sufficient for most atSigns representing people or things. ‘Busier’ atSigns (e.g. for companies) can be configured with more CPU and RAM as needed.
atDirectory
What does “resolvable address” mean for an atSign?
In order for an atSign to communicate with another one on the internet, it needs to locate the atServer that can send and receive information securely on its behalf. This location is found using the atDirectory service (root.atsign.org). This directory returns the DNS address and port number of the atServer for any atSign that it has a record for. The atDirectory service contains no information about the owner of the atSign.
Edge Devices
What is an edge device and what is edge to edge encryption?
An edge device is any device located on the edge of a network that might produce or consume data. This can include smart-phones, personal computers, servers, IoT devices, gateways, and more. Edge-to-edge encryption is an extension of end-to-end encryption which ensures that data is encrypted during transmission and only made available in the clear from edge devices. atSigns store their cryptographic keys on the edge devices, which in combination with the atDirectory, atServers, and Atsign’s SDKs, create a system which features true edge-to-edge encryption. The atDirectory is never used to route (personal) data, it is purely used for looking up the DNS address and port of an atServer you wish to connect to. atServers are used to transmit, receive and store encrypted data, with no access to the cryptographic keys to decrypt said data. Only data that has been intentionally made public will be stored on the atServer in the clear.
How do you eliminate network attack surfaces from IoT devices?
For Atsign enabled devices, connections are always outbound to its atServer (to which it is cryptographically bound). All desired inbound communications have to be encrypted and sent to the edge device’s atServer. Once the sender of the incoming data is authenticated, the edge device can pick up that data the next time it connects, or immediately, if it’s already connected.
This ultimately means that there is no need for the device to have open ports listening for connections, no need to know the device’s IP address, and, in general, no need for direct network access to the IoT device. The net effect is that there is no network attack surface.
An example implementation can be seen in SSH No Ports.
How can Atsign technology work without static IPs?
Atsign enabled devices do not require static IP addresses because all connections are outbound from the device to its atServer. Therefore, the device’s IP address can change as needed. atServers, however, do have static DNS addresses.
How are my devices addressable when they cannot otherwise be accessed?
Atsign technology provides bidirectional communication between the device and its atServer with connectivity originating outbound from the device. This means that the device is always addressable so long as it is able to connect to the internet, without setting up port forwarding and even if it’s behind a firewall or router.
How is possible to communicate with the device when no network ports are open?
You can communicate with a device by sending whatever communications you need to its atServer. Its atServer authenticates you as an acceptable sender of information and sets up a notification that the communication is available for the device. If actively connected, the device is notified immediately and the communications are received by the device. If not connected, the device will be notified immediately upon connecting with its atServer and the communications are received. Once it has the communications, it decrypts and does whatever it’s programmed to do with the communications.
A great example of this is SSH No Ports which provides a way to SSH to a remote Linux host/device without that device having any ports open (not even port 22). All network connectivity is outbound and there is no need to know the IP address the device has been given. As long as the device has outbound access to the Internet, you will be able to connect to it.
Does this technology require passwords?
No. Atsign technology strips things down to the protocol level, creating both zero trust and zero configuration environments – completely without passwords. It eliminates all attack surfaces created by over-complexity, and simplifies device administration in the process.
Authentication with Atsign technology is mutual, cryptographic, and does not depend upon any shared knowledge (like passwords) between the endpoints. This means that it is no longer possible to compromise credentials from a centralized resource.
What is the latency on Atsign technology?
In the common situation where @atSign_1 is sending end-to-end-encrypted messages to @atSign_2, once the various socket connections have been established, the end-to-end latency excluding speed-of-light is typically between 4 and 15 milliseconds including encryption, decryption and atServer work (storing and forwarding).
What should I install on my IoT devices to use Atsign Technology?
Updates to the device’s software need to occur to work with Atsign technology. This is generally done by the device software developers using the Atsign SDKs to update the device’s software to incorporate the atClient into the software that’s getting data from sensors or sending data to actuators. The atClient will then take data from the device, encrypt it with the intended recipient(s) public key(s) and send it to the desired recipients.
For packaged solutions, like SSH No Ports, the software needed will vary. For example, if the administrator also wants to use SSH No Ports, they would need to also install the SSH No Ports Daemon on the device. Installation instructions for SSH No Ports can be found on the NoPorts web site.
These updates can be made using the existing mechanism used to update the device’s software. During this process a couple of small libraries would be added to the device (SSHNPD and atClient) and a “driver” that would allow the device to pass any files (images) off to the atClient for delivery.
Updating the device’s SIM (if it has one) is optional. If you want to use the SIM as the TPM (Trusted Platform Module) IoT Safe would need to be installed. In this case, this is where atSign and cryptographic keys would be stored. This update would be made over whatever existing mechanism there is for making OT updates on the SIM
If you do not want to use the SIM as a TPM you could store the atsign and keys in the device’s:
- TPM (if it has one), or
- File system – this is the least secure option because they could be compromised if someone gets physical access to the device.
What are the hardware and software compatibility requirements?
Processors
- x64
- ARM (ARMv7, ARMv8, M1/2 (Apple)
- RiscV – Beta
Operating Systems
- Linux
- Mac
- Windows – Coming soon!
Other
- Microcontrollers
If I have very old sensors and hardware that don't have a lot of processing power, how will your technology work?
Old sensors aren’t a problem as long as there is a microcontroller (MCU) with enough RAM to handle crypto operations. We’ve already done extensive testing with Raspberry Pi Pico (192kB RAM) and various ESP32 based platforms. It may be possible to get onto 128kB MCUs. Anything smaller than that is likely to need the addition of another processor to the system.
How can I assign an atSign to an IoT device?
There are a wide variety of ways in which an atSign can be assigned to a device. They can be assigned manually via a physical connection or an OTA. Or, they can come pre-assigned by the manufacturer of the device or SIM.
For IoT devices, the best practice is to define one or more atSigns(s) for administration and data ownership.; They need not be the same, depending on the use case. That way, it is easy to provide separation between device administration and data ownership and privacy. There are libraries available that make that an easy task.
Can I change atSigns on my IoT devices?
It depends. If the atSign is incorporated into the device’s eSIM/iSIM, then it probably is not possible. If it’s not in the SIM, it’s certainly possible, however there generally is no need to change the atSign for a device. More common would be to change the designated device or data owner to a different one in the event that the device is sold to someone else. Even more common would be to designate one or more data owners for the device who can then decide which atSigns to share their data with to ensure privacy.
Encryption
Why does Atsign use encryption?
We want to ensure that it is “provably true” that data is accessible only to the intended parties and to no one else. We use cryptography to achieve this. The primary feature of the system is that (a) the asymmetric cryptographic keys are cut and kept on the edge device where the data is created, and (b) the symmetric encryption keys used for sharing encrypted data are themselves encrypted using those asymmetric keys, and shared via the atProtocol. This means only the creator and recipient have access to the encryption keys needed to decrypt the data. Nobody else, including the operator of the infrastructure can ever access your private data.
A number of technologies do encryption. How is Atsign different?
Atsign is unique because we make it extremely *easy to use* cryptographic methods to exchange information. Why aren’t there more than a handful of end-to-end-encrypted apps out there even though the cryptography algorithms themselves have been around for decades? It’s because it is hard to build and operate this stuff. With Atsign technology, that’s no longer the case.
With Atsign’s technology, the cryptographic keys are cut at the edge and they belong to whoever owns the atSigns – there is no centralized cryptographic key management. Even Atsign as a company has no way to get the cryptographic keys and thereby the data truly belongs to the owner of the atSign.
What type of encryption algorithms are used?
Atsign technology uses both symmetric and asymmetric encryption algorithms. Both encryption methods use keys to encrypt and decrypt data. The main difference is that symmetric encryption uses the same key to encrypt and decrypt data. In contrast, asymmetric encryption uses a pair of keys – a public key to encrypt data and a private key to decrypt information.
Our goal is always to use best-in-class encryption tech in our SDKs thus Atsign technology provides support for different encryption algorithms. Currently this includes RSA-2048 and ECC asymmetric encryption and AES256 symmetric encryption in our end-to-end solution, but the protocol and the technology has been designed to be extensible, so that others (for example post-quantum-cryptographic algorithms) can be added as necessary.
- Symmetric encryption:
For reasons of efficiency and large data size capacity (including data streams), Atsign technology uses symmetric cryptography to encrypt data. Currently, only AES 256 symmetric cryptography is supported.
- Asymmetric encryption:
Atsign technology uses asymmetric cryptography for authentication purposes, non-repudiation purposes (data signing), and for ensuring that symmetric keys are shared with others in a cryptographically secure way. Asymmetric encryption algorithm supported options include RSA (2048) and ECC.
- Note: asymmetric and symmetric encryption can be used in combination:
When data is to be encrypted, Atsign uses symmetric cryptography to encrypt the data and asymmetric cryptography for the exchange of the symmetric shared keys. This means that data can be uniquely encrypted for the recipient such that only they can decrypt and use it.
What are the different types of cryptographic keys that are used by Atsign technology?
Cryptographic keys are required for authentication and data encryption purposes. The following are the various cryptographic keys that are managed by Atsign technology.
Authentication:
- pkamPublicKey / pkamPrivateKey key pair (asymmetric)
- pkam public keys are held on the atServer; pkam private keys are only ever held on the edge, and the technology allows for the private keys to be held in a secure element and for the encryption / decryption / signing operations to be delegated to the secure element.
Asymmetric encryption:
- encryptionPublicKey / encryptionPrivateKey key pair (asymmetric)
- Encryption public keys are held on the atServer. When one atSign wishes to exchange a symmetric key with another atSign, the first atSign retrieves the second atSign’s encryption public key, encrypts the symmetric key with it, and then sends the encrypted symmetric key to the second atSign. The second atSign then decrypts the symmetric key using their encryption private key.
- This keypair is also used for data signing and for signature verification.
Symmetric encryption:
- Symmetric keys are used to encrypt the actual data which is being exchanged. Symmetric keys themselves are securely exchanged using the asymmetric encryption keypairs described above
- atSigns also create symmetric keys to secure information which they want to store for themselves only.
How are these keys protected?
Asymmetric key-pairs are cut on the edge devices, and private keys never leave the edge devices. There is no centralized key management. Ideally, these keys are cut by and kept in a secure enclave (TPM, SIM or other) and, while they can be used for cryptographic operations, the private keys should be kept isolated from other forms of access.
What happens if the keys are lost?
Atsign cannot help you retrieve your keys if you have lost them because the keys were generated by your device. However, you still own your atSign and can reset your atSign by contacting support@atsign.com where you can generate a new set of keys and use the same atSign.
What controls are in place to protect compromised clients and IoT devices (i.e. stolen devices) since data encryption keys are stored on the edge devices (i.e. client and IoT devices)?
There are many options depending on use case:
- The atSign can be reset on the my.atsign.com portal and any compromised keys are now useless.
- Keys can be cut in hardware and the private key is never exposed directly, using a SIM or TPM.
- Keys can be exported and imported if, for example, the same atSign is required on multiple devices. This option will soon be removed as each atSign will be able to have multiple keys, across multiple devices. In that case, the “master” key can be used to delete access for stolen or lost devices. A second factor (e.g. biometrics) protects the master key.
Data Structures
What is the easiest way to get started with your technology for IoT?
The best way to get going is to give it a try. We offer a product called SSH No Ports with all you need to quickly and easily begin, and are always available to help if needed.
You can also check out Atsign’s GitHub organization.
What is the data exchange and persistence model for Atsign technology?
The atProtocol default persistence model is a simple ID-value-store. The record IDs themselves have a syntactical structure which is also used in the protocol exchanges between clients and atServers, and between atServers.
- The record ID structure is: [cached:]<visibility scope>:<entity ID><owner’s atSign> – the different fragments are explained below
- NB: Record IDs are always stored as lower-case.
Visibility scope: Visibility scope defines who is able to see and access some data
- Public scope (e.g. public:location.some_app@alice) indicates that the information is intended to be made “public”, i.e. available to anyone. It can be shown in an atServer scan without authentication, and the data is not encrypted.
- Private scope: (e.g. @bob:phone.some_app@alice) is for information that is intended to be shared privately with another atSign. In the example above, @bob is the visibility scope for this particular record. It will only be shown in a scan for the owner and recipient atSigns after authentication. In addition, the data can only be decrypted by the owner and recipient using their private keys.
Entity ID and Namespace: (e.g. @bob:work.email.an_app@alice)
- NB: @bob:work.email.an_app@alice is stored as a fully distinct record from @charlie:work.email.an_app@alice, and you could choose to store completely different information in those two records. However, thinking of the entity ID as logically unique, and representing the same underlying information, removes an opportunity for confusion and we strongly recommend this.
- An entity ID can be any alphanumeric string. Because record IDs are always stored as lower-case, we recommend using ‘snake case’ (i.e. home_phone_number rather than homePhoneNumber)
- The namespace part (‘an_app’ in the example above) is important to control which applications are able to read, write and synchronize data between a client application and the atServer that supports all your applications.
Owner atSign: (e.g. @bob:phone.buzz@alice)
- The owner atSign indicates the atSign that created the record
All of the above combine to make a record ID a full atProtocol URL
Cached tag: (e.g. cached:@bob:phone.buzz@alice) indicates that the data was created by another atSign, encrypted and shared with your atSign and the metadata setting allows it to be cached on your data store This enables offline support in Atsign enabled apps and improves performance as it is available locally.
Can I integrate your technology with existing cloud and IoT platforms?
Yes. Atsign technology is powered by the open atProtocol and an SDK to help integrate it with almost anything. We offer a variety of open source libraries, widgets and connectors that allows for these integrations to come to life (see Atsign’s GitHub organization). Our default cloud provider is currently GCP, though our tech is compatible with all cloud solutions as well as any on premise infrastructure, if preferred.
Is it possible to share only some of the data on an IoT device with one party, while also sharing all (or different segments of) the data to another?
Yes. You can set up your devices so that different data sets are sent to different recipients. Each data set is uniquely encrypted for the intended recipient.
What are some Atsign technology use cases?
Atsign technology can applied to virtually any use case where information must be exchanged privately and securely. Based on hundreds of conversations with customers, developers, and technology partners, we found an acute need in the IoT market. Here are some of the IoT use cases:
- Network equipment manufacturers are removing all network attack surfaces without sacrificing capabilities.
- Faster deployment of medical devices to homes and ambulances (months to minutes).
- Better security, lower cost and reduced power consumption for solar powered WiFi hotspots with 5G backhaul.
- Secure transmission and transformation of data from legacy protocols (e,g. SNMP 1.0) with zero network attack surface and end-to-end encryption.
- Privacy and device security for directly accessing images and live videos from cellular connected, battery powered remote cameras without the need for expensive backend infrastructure.
- Transformative “customer at the center” for insurance customers where data is owned and controlled by the customer and sharing consent is cryptographically provable.
- Secure, untraceable file sharing for war afflicted regions.
- Private, end-to-end encrypted and totally secure sharing of contact data.
Pricing
How does pricing work?
There are two components to our pricing:
- atSigns : Every atSign is unique on the protocol. Based on the nomenclature of the atSign, we have different pricing models. For each atSign there is a one time fee to procure the atSign and an annual renewal fee of $10 irrespective of the atSign. You can, of course, register randomly generated free atSigns (which have no renewal fee), but most people prefer names and nomenclature that follow a certain pattern for entities and things.
- atServers : Every atSign has an atServer. By default, we run these atServers on the GCP cloud, and pay a monthly charge. atServers can be run by the owner of the atSign at any internet-addressable cloud or on-premise server.
General
How does Atsign compare to other IoT security solutions?
The atProtocol default persistence model is a simple ID-value-store. The record IDs themselves have a syntactical structure which is also used in the protocol exchanges between clients and atServers, and between atServers.
- The record ID structure is: [cached:]<visibility scope>:<entity ID><owner’s atSign> – the different fragments are explained below
- NB: Record IDs are always stored as lower-case.
Visibility scope: Visibility scope defines who is able to see and access some data
- Public scope (e.g. public:location.some_app@alice) indicates that the information is intended to be made “public”, i.e. available to anyone. It can be shown in an atServer scan without authentication, and the data is not encrypted.
- Private scope: (e.g. @bob:phone.some_app@alice) is for information that is intended to be shared privately with another atSign. In the example above, @bob is the visibility scope for this particular record. It will only be shown in a scan for the owner and recipient atSigns after authentication. In addition, the data can only be decrypted by the owner and recipient using their private keys.
Entity ID and Namespace: (e.g. @bob:work.email.an_app@alice)
- NB: @bob:work.email.an_app@alice is stored as a fully distinct record from @charlie:work.email.an_app@alice, and you could choose to store completely different information in those two records. However, thinking of the entity ID as logically unique, and representing the same underlying information, removes an opportunity for confusion and we strongly recommend this.
- An entity ID can be any alphanumeric string. Because record IDs are always stored as lower-case, we recommend using ‘snake case’ (i.e. home_phone_number rather than homePhoneNumber)
- The namespace part (‘an_app’ in the example above) is important to control which applications are able to read, write and synchronize data between a client application and the atServer that supports all your applications.
Owner atSign: (e.g. @bob:phone.buzz@alice)
- The owner atSign indicates the atSign that created the record
All of the above combine to make a record ID a full atProtocol URL
Cached tag: (e.g. cached:@bob:phone.buzz@alice) indicates that the data was created by another atSign, encrypted and shared with your atSign and the metadata setting allows it to be cached on your data store This enables offline support in Atsign enabled apps and improves performance as it is available locally.