Response to concerns about NanoKVM security

[Zepan]

In apalrd's recent video (https://www.youtube.com/watch?v=plJGZQ35Q6I), apalrd raised several security concerns regarding NanoKVM.
We have carefully watched the video—some parts are fair, while others result from an incomplete understanding of the product.
To help users better understand these concerns, we are providing a unified response under this issue. We welcome objective discussions.

Security vs. Usability Trade-off

Before discussing the details, we want to clarify a fundamental fact: security and usability are inherently contradictory to some extent. If one pursues absolute security, usability will be significantly compromised. apalrd represents a group of users who prioritize security to the extreme. However, based on our customer support records, a large proportion of users care more about ease of use.

For example, we receive multiple emails daily from users who have forgotten their self-set passwords and need help recovering them. apalrd also pointed out that our page "reminds" users to change their passwords rather than "forcing" them to do so, considering this a security risk.

In fact, we did consider forcing password changes during the initial product design. However, after shipping the alpha version, we found that a significant proportion (perhaps over 50%) of our users are beginners. If we force them to change their passwords, they are likely to forget them. Additionally, those who forget their passwords typically do not read the wiki (which contains instructions for physical factory reset). This would leave them unable to use the product or require them to send support emails.

Thus, we chose to remind rather than force users to change their passwords. apalrd mentioned that many IoT devices have similar security issues, but aside from actual security risks, some design choices are compromises for usability.

Responses to Other Concerns Before Discussing Security Details

We understand apalrd’s strong focus on security. However, as a product designed for a wide range of users, we must balance security and usability. We believe different user groups have different needs, so we made trade-offs in our product design accordingly. If apalrd had carefully read the wiki before using the product, some misunderstandings in the video could have been avoided.

Responses to Non-Security Design Issues

1. Does the full version require disassembly for reflashing?

• No. We considered factory reset and reflashing methods in the design, as detailed in the wiki. By holding the BOOT button while powering on via USB, the device enters flashing mode. At this point, U-Boot enters UMS mode, allowing users to flash the image via dd or BalenaEtcher.

2. Is using Type-C for ATX power control an abuse of USB cables?

• Similar products use RJ11 for ATX power control, but this has two issues:
  1. Size: While RJ11 is acceptable for PiKVM, it is too large for NanoKVM.
  2. Availability: RJ11 cables are not always readily available at home. If users lose them, they must pay extra for replacements.
• We specifically chose the smaller Type-C interface, allowing users to use readily available A-to-C cables of flexible lengths.
• Regarding apalrd’s concern about potential damage from plugging in a normal USB cable, we considered this issue during design. Our implementation ensures that even if a standard USB signal is inserted, it will not cause electrical damage.

3. Issues with PCIe naming and installation

• The name “PCIe” was chosen based on a Twitter poll. Although it does not use PCIe communication, users still preferred this name for clarity.
• apalrd did not carefully read the wiki or fully understand the PCIe version’s design. He assumed it was only mechanically fixed and did not address wiring or electrical functions.
• The PCIe version was specifically designed for ATX case installation. While it has an external USB-C port, our recommended installation method is internal, using the provided DuPont cables to connect to the internal USB header, avoiding extra external wiring.
• The PCIe slot is not just for mechanical fixation—NanoKVM draws power from PCIe 3.3Vaux, which remains powered even when the PC is off. Thanks to NanoKVM’s ultra-low power consumption (<1W), it can run continuously from 3.3Vaux without external power.
• In fact, NanoKVM-PCIe requires only an HDMI connection to function externally, contrary to apalrd’s claim that it still needs multiple cables.
• In an earlier design, we even considered connecting the PCIe wake# signal for wake-on-LAN functionality but later removed it based on overall usage considerations.

4. Misunderstanding between system images and app versions

• In the video, apalrd mentioned that the system image was from three months ago and outdated. However, he confused the system image with the app version.
• The system image serves as a stable base. Once the fundamental drivers are in place, it does not need frequent updates.
• However, we continuously update the app, incorporating user feedback, feature enhancements, and bug fixes—even modifying original system files when necessary.

5. Misinterpretation of the open-source repository’s purpose

• apalrd assumed we rely on the community for development. In reality, most PRs are for UI language translations, with very few for core functionality (for which we offer free new products as rewards).
• We never intended for the community to take over development. Based on our experience with many prior open-source projects, commercial product development cannot rely on uncertain community contributions.
• The main reason for open-sourcing NanoKVM is transparency—to prove there are no "Chinese backdoors." As apalrd’s own analysis confirmed, there was no evidence of intentional backdoors.

Response to Security Concerns

To address the security-related concerns, I have categorized all the issues and will respond accordingly.

Design Trade-offs for Usability and Availability

1. Password Change Policy
   -As mentioned earlier, we chose to "remind" users to change their passwords rather than "force" them to do so.
2. Forced DNS Modification

• Some users in certain regions experience domain resolution failures with their local DNS providers, preventing access to Sipeed’s servers and causing update failures. To ensure availability, we enforced the use of reliable DNS services. While this decision may raise security concerns, it was made purely to guarantee usability for all users.
• The issue you mentioned—"installation failure due to network restrictions in China"—is an example of such network-related problems.
• Once again, security and usability are often in conflict, and we aim to strike a balance. Some harmless actions may cause unnecessary concerns.

3. Bundled Outdated Version of Tailscale

• During the Alpha hardware release, we did not preinstall Tailscale in the image. However, some users in certain regions were unable to access Tailscale's official website, so we used a CDN to distribute a fallback version.
• In the final official image and hardware versions, this fallback link is not needed.
• This was purely a usability-driven decision—just because your network can download Tailscale without issues, it doesn't mean all users around the world can do the same.

Non-Security Issues / Other Feature Enhancements

1. Default Installation of tcpdump and aircrack

• These packages were enabled by default in the original SDK for the SG2002 platform, and we initially retained the default configuration without much attention.
• However, these tools have proven useful for diagnosing network issues users encounter. This has been evident in comments under your video and discussions on GitHub issues.
• Additionally, our PCIe version includes WiFi support, and to avoid fragmenting the image versions, we provide a unified firmware image. As a result, some software packages may be present even if they are not immediately needed for a specific hardware variant.

2. NanoKVM Lacks MFA Support

• This is something better suited as a "TODO" item, and we will update the README roadmap accordingly.

3. Closed-Source Libraries

• This issue has already been addressed in the corresponding GitHub issue.
• NanoKVM is a side project of MaixCAM, and for rapid development, we reused some proprietary MaixCAM libraries.
• However, these libraries only handle chip-specific video encoding/decoding and do not contain anything concerning.
• In fact, community developers have already reverse-engineered and reimplemented the necessary functionality.
• In the next version, we will remove these dependencies to eliminate unnecessary speculation.

Security Concerns Stemming from Tailscale or Network Configuration

1. NanoKVM as a Router

• The Tailscale startup script sets ip forwarding = 1, effectively turning the device into a router.
• Since enabling Tailscale automatically configures this setting, we provide users with the option to enable or disable Tailscale.
• Users can also manually remove /etc/sysctl.d/99-tailscale.conf if needed.

2. NanoKVM Identified as an "InternetGatewayDevice"

• It is enabled by default in the original SDK for the SG2002, we can disable it next time

Beneficial Security Recommendations

1. Potential Issues with SSH Enabled by Default
   Initially, NanoKVM was designed as a product for homelab developers. Therefore, we set the product to "Developer Mode" by default, enabling SSH to facilitate network diagnostics and recovery for developers. Many of our previous designs and configurations, as well as our earlier products like SBCs and AI Cameras, were also tailored for developer users. However, as NanoKVM reaches more general users, it is indeed time to default to a "Regular User" mode, with "Developer Mode" requiring manual activation.

2. Hardcoded Keys in TypeScript
   Yes, this was an improper practice, a flaw left over from the early rapid development stage. We plan to move the keys into configuration files in the next version, which is expected to be released this month. This improvement will further enhance product security. However, it is worth noting that the primary security risk associated with this issue is man-in-the-middle attacks, meaning that the risk arises mainly when your network is untrusted or malicious. In such cases, the number of potentially compromised devices around you may be greater than expected.

3. Lack of APP Update Verification

Similar to the previous issue, we will add verification in the next version. The primary risk also comes from man-in-the-middle attacks.

Summary

We are always committed to finding the best balance between security and usability and appreciate the feedback from apalrd and other users.
We will continue improving NanoKVM to ensure it meets the security needs of advanced users while remaining simple and user-friendly for beginners.
We welcome all users to transparently discuss and provide suggestions in an open-source environment. Whether the concerns are genuine security issues or security concerns influenced by bias, they can be properly addressed in a transparent, open discussion.

Additionally, we recommend users read our Wiki documentation before using NanoKVM to fully understand its features and usage.

For any questions, our technical support team is always available: kvm@sipeed.com.

[alexhk]

When you say "next version", are you talking about a new hardware (NanoKVM Pro), or a software update for current NanoKVM users?

[mcsrobert]

This feels really dismissive. Let's take the hardcoded DNS servers as an example, but this applies to multiple issues responded to here.

Hardcoded DNS is a pretty obvious bad practice. Your reply is: "Some users in certain regions experience domain resolution failures with their local DNS providers."

Then why not have a sane default and offer those few users who need to take extra steps the ability to easily change the DNS server?

Just because users in China are behind a firewall, doesn't mean that by default this device should ignore the DNS server in my network.

[wj-xiao]

When you say "next version", are you talking about a new hardware (NanoKVM Pro), or a software update for current NanoKVM users?

The software update.

[wj-xiao]

This feels really dismissive. Let's take the hardcoded DNS servers as an example, but this applies to multiple issues responded to here.

Hardcoded DNS is a pretty obvious bad practice. Your reply is: "Some users in certain regions experience domain resolution failures with their local DNS providers."

Then why not have a sane default and offer those few users who need to take extra steps the ability to easily change the DNS server?

Just because users in China are behind a firewall, doesn't mean that by default this device should ignore the DNS server in my network.

We will remove the modification operation and no longer modify the DNS configuration file.

[sean-wilkinson]

Hardcoded Keys in TypeScript
Yes, this was an improper practice, a flaw left over from the early rapid development stage. We plan to move the keys into configuration files in the next version, which is expected to be released this month. This improvement will further enhance product security. However, it is worth noting that the primary security risk associated with this issue is man-in-the-middle attacks, meaning that the risk arises mainly when your network is untrusted or malicious. In such cases, the number of potentially compromised devices around you may be greater than expected.

Why move the keys to a config file? The problem here is the fact that the password is encrypted and can be decrypted with a key.

1. The password and salt should be hashed by the browser using a one way hash function such as sha256.
2. The hash is sent over the network
3. The Server (NanoKVM) should compare the hash with the hash stored locally.
4. If the hashes match authentication was successful.

Employing Symmetric-key cryptography such as AES256 for login functionality such as this is very suspicious as it allows a man in the middle to decrypt the password if they have the key.

Using a one way hash function does not allow a threat actor to recover the password unless they have a very VERY large GPU farm to crack the hash.

These are basic security fundamentals.

[PatrickHuetter]

Dear Sipeed Team,

I assume that due to the recently released video, you will now receive increased feedback as well as critical messages—some of which are justified. However, I am convinced that you can use this situation as a great opportunity to become even more successful in the long term.

My advice: Support the open source community by releasing all the information needed to build a clean and efficient open source firmware. You will see that many more people will be willing to purchase your hardware because that is your unique selling point!

Personally, I would have bought the nanoKVMs much earlier if the open source aspect had been clearly resolved and everything had been made open source. Don’t be afraid to build something great together with the community—and don’t fear competition. If you deliver top-notch hardware while quickly and sustainably fixing the software issues, your project will be celebrated and widely adopted.

I truly appreciate the price/performance ratio of your hardware—even compared to the JetKVM. Now it’s up to you to optimize the software and release it fully open source. Be smart and let the community help you.

Best regards!

[ddscentral]

I personally find apalrd’s security concerns to be perfectly valid, given what type of device this is. This is a KVM device which is used to REMOTELY CONTROL a computer.
In my opinion, security and transparency should be your top priorities, even if they can sometimes come at a cost of ease of use. This device is not a toy to play with. Well, unless you want to treat is as such.

I have acquired several NanoKVM devices but so far I only put one of them in service for testing/tinkering purposes.
I have serious doubts about putting others into service with the software in it's current state. Even though I do like the hardware.

[gshpychka]

Why don't you respond to the specific issues in this repo, some of which are about the concerns you're addressing?
Opening a tracking issue is okay, but you should respond to the issues as they're opened, not wait for a youtube video to address them in a new and separate issue.

#245
#250
#289
#192
#248
#295
#197
#294

[apalrd]

I didn't pull my comments out of thin air. I read all of the Github issues that have been accumulating here for months before making the video, and covered the ones I thought were the most significant.

The lack of action on these issues (here, on Github) speaks volumes to your commitments to security in the product.

[TheSp1der]

Honestly, I don't think the review by apalrd's video was fair. I knew going in that this device was from a possible suspect source, in reality or not, but let's be clear everything on my network is a suspect. So, I treat it that way. Using sensationalized words and phrases like "Backdoor" and "Victim's computer" seems a bit unfair when there was no evidence to indicate any of that was true.

I was suspect of these and isolated them, but, honestly, Google devices make more scary calls than this thing does.

I'll touch on a few issues here with my two cents, but I feel like @Zepan 's comments were rather sufficient.

• First, hard-coding dns servers IS bad practice, but its hardly out of the norm these days. Companies fed up with project's like Pi-Hole are starting to use this more and more frequently. I have even seen some dns-over-tls and https requests happen without my consent (from other devices, looking at you, Google.). So, I don't feel that call out is exactly fair.
• The root password, ok, so it's root? I didn't buy this thing to manage a server running in production in some fortune 500 company. I also expect to be able to manage it, which I can. I'm more concerned over the weak ssh ciphersuites this thing supports, but it's not a powerful (or expensive) device.
• Lack of TLS. Yep it lacks TLS, but you can enable that. The documentation even has instructions for you, but it does impact performance. Again, it's not a powerful (or expensive) device.
• I agree the update method requires a bit of a re-think. I would like to see the sources open as well and signed at a minimum.
• Tailscale, is installed and the daemon is running and checking in with the tailscale network. Yep, that's how that works! The odd thing here, it's not happening on my 5 devices. I suspect that is because I received my device very early, before the tailscale support was added. I have not seen this connectivity, but I also either disabled talescale or it was never enabled in the updates I have received. Tailescale is awesome and I would naturally be suspicious, but it does a lot on it's own to work, and this might not be the NanoKVM doing scary things, but tailscale. I have not seen any evidence that a tailescale network was added without my knowledge. I would rather see this disabled by default, as is my experience, but that seems to have changed during recent revisions.

In summary, yes, there are some security issues, outdated packages, weak ssh ciphers/hmac, poor update mechanism/validation to name a few. But it's a $20.00 KVM. I didn't expect the gold standard here, I trust it about as much any device, but I have seen little evidence that this is a "backdoor".

I want to say something about the timing of the release of a competing kvm product, but I have no evidence to even make an assumption. What I do want to see happen is Sipeed make good on their answers here and opensource the rest of the project, but I don't expect perpetual updates for a $20.00 KVM.

[That-Dude]

This is a KVM that is going to be connected to servers that are logged into admin / root sessions. There is no trade off with usability versus security, its 100% security first, usability second.

All of @apalrd points are valid. Your hardcoded keys, password management, unverified downloads from remote servers, dns bypassing and tailscale on by default are a security disaster waiting to happen.

Fix these issues and become the homelabbers product of choice, you'll quickly gain trust and can break into the massive SME market. If you don't do it a competitor will and you're going to miss out on a huge opportunity! I have 4 nanokvms and i think the hardware is great, but they live in a restricted vlan for the reasons listed above.

[rosshiga]

I agree it's alot of criticism for a hobby level just out of beta product but the attitude that it's just going to be used in home lab is why crap IoT security exist. This is a remote access device. Secured by design is a philosophy and unless you change your mindset the product will never be secure enough for a RAT.

The glaring difference here between you and JetKVM is that when stuff like this comes up JetKVM Team says "no, user, you will hurt yourself" in the long term if you don't change your password. You should not be making the product more insecure. Convenience is at the expense of security and it's clear what you folks believe is more important.

[swaits]

There is no reason (maybe other than ntp) a KVMoverIP device needs to reach out to the public Internet, ever. No good reason. At least not by default.

Any claim otherwise is in very bad faith.

Now, I'm going to assume you're not doing anything malicious. But, it doesn't change the need to come completely clean and fix it. Why? Hanlon's Razor:

Never attribute to malice that which is adequately explained by stupidity.

[bddanford]

Could we get the most current release of the firmware posted maybe? Some of the glaring issues can be quickly resolved. I would really like to see these devices work and have some reasonable expectation of a somewhat secured by default. If this stuff was mostly done to make PoC/testing easier, then thats fine, tell us, be up front, tell us what and why its doing it, and keep it a beta product until you are ready to lock it down more and move to more of a release candidate testing phase.