如何唯一标识一个网络?

发布于 2024-10-25 15:07:07 字数 494 浏览 1 评论 0原文

假设我想创建一个应用程序,其中存储的数据是加密的,因此只有我的应用程序才能读取它。

但我希望仅当用户位于特定网络上时才能访问该应用程序。 例如,该应用程序是一个处理医院医疗记录的 Android 应用程序。 如何确定设备已连接到医院网络?这个想法是,在这个网络之外,该应用程序将无法运行。

这个问题与无线网络、无线设备或 Android 没有特别关系,这是编程和网络识别的一般问题。

证书可以做到这一点吗?我对此很陌生。 网络“标识符”可以伪造吗?例如,我非常确定 WiFi SSID 很容易伪造。

干杯。

更多详情: 我们假设本地数据的目的不是为了“离线模式”,而是为了避免网络延迟。在这种情况下,只有连接到特定网络时,数据才需要保持可访问性,以防设备被盗。

但是,如果无法确定网络的身份……那么有一个服务器可以回答“嘿,我是否在正确的网络上?”如果没有回应我就知道我没有选择正确的人? (或者服务器只是不响应......)但是,同样,如果应用程序被黑客攻击,那也可以被伪造。

Let's say I want to make an application where stored data is encrypted so only my application is able to read it.

But I want the application to be accessed only if the user is on a particular network.
For instance the application is an Android app that deals with medical records in a hospital.
How to be sure that the device is connected to the network of the hospital ? The idea is that outside this network, the app won't work.

The question is not particularly related to wireless networks, wireless devices or Android, this is general to programming and network identification.

Could a certificate do that ? I'm new to this.
Does a network "identifier" could be faked ? For instance I'm pretty sure that a WiFi SSID is easy to fake.

Cheers.

More details:
Let's assume that the point of the local data is not for an "offline mode", but to avoid network latency. In that case, the data needs to remain accessible only if connected to a particular network, in case the device is stolen.

But if there is no way to be sure of the network's identity... What about a server that would answer to the question "Heya am I on the right network ?" and if no response comes out I know that I'm not on the right one ? (Or that the server just does not respond...) But, again, if the app is hacked, that can be faked too.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

天暗了我发光 2024-11-01 15:07:07

有趣的问题。

一般来说,将数据存储在本地的目的是为了可以在“离线”时访问数据。

然而,我认为这里可能存在一些潜在的误解。想必您想要这样做的唯一原因是尝试防止被盗设备泄露其秘密。事实是,你不能。如果设备不再处于您的物理控制之下,那么它被黑客攻击只是时间问题。

如果我们谈论敏感数据,则不应将其存储在设备上。相反,设备应该在需要时从服务器检索所需的数据,并在不再需要时在本地删除它。

事实上,您希望设备仅在连接到本地网络时工作,这意味着您可以实现此目标。

顺便说一句,这就是“远程擦除”之类的东西存在的原因。这也是为什么每次设备连接到网络时都需要测试其身份验证和授权。要点是,如果有人报告设备丢失或被盗,那么您需要能够从网络中禁止它,并且如果设备支持此功能,则可以远程禁用它。

请记住,完全有可能从网络中拉出设备,从而禁用远程擦除的执行。


如果不这样做,您绝对无法确保设备位于给定网络上。所有这些都可以伪造。设置给定名称的路由器并更改其 MAC 以伪装成任何名称,并为其分配特定的 IP 地址,这有点微不足道。出于所有意图和目的,它可以看起来与您拥有的接入点一模一样……而这只是您可以在当地计算机商店购买的正常运行的无线路由器。

Interesting problem.

Generally speaking the purpose of storing data locally is so that it can be accessed while "offline".

However, I think there may be some underlying misconceptions here. Presumably the only reason you'd want to do this is to try and prevent a stolen device from giving up it's secrets. Fact of the matter is, you can't. If the device is no longer under your physical control then it's just a matter of time before it can be hacked.

If we are talking about sensitive data, it shouldn't be stored on the devices. Instead the device should retrieve the data it needs from your server when it needs it and delete it locally when no longer necessary.

The fact that you want the device to only work when connected to your local network implies that you can accomplish this goal.

As a side note, this is why things such as "remote wipe" exist. It's also why every time the device connects to your network it needs to test it's authentication and authorization. Point is if someone reports the device lost or stolen then you need to be able to ban it from your network AND, if the device supports this, remotely disable it.

Bearing in mind that it is entirely possible to pull a device from the network and therefore disable a remote wipe from executing.


With that out of the way, there is absolutely no way you can ensure the device is on a given network. All of that can be faked. It's kind of trivial to setup a router of a given name and change it's MAC to masquerade as whatever, and assign it certain IP addresses. For all intents and purposes it could be made to look exactly like an access point you have... And that's just with normal run of the mill wireless routers you can buy at your local computer store.

面如桃花 2024-11-01 15:07:07

您可以编写程序,以便将解密数据的密钥存储在医院网络的服务器上。如果您的程序从不存储密钥,那么某人就更难(尽管并非不可能)在网络之外访问设备的数据。

正如克里斯指出的那样,远程擦除肯定是可取的。您可以输入逻辑,以便如果设备在未连接到网络的情况下尝试读取数据,它会擦除​​数据(这可能会导致意外擦除)。黑名单也很好,因此如果设备尝试重新连接到网络,您基本上可以将其屏蔽。一件非常糟糕的事情是,如果您遇到网络中断,并且您的所有设备都被意外擦除。

You could write your program so that the key to decrypt the data is stored on a server on the hospital network. If your program never stores the key, it makes it harder (although not impossible) for someone to access the device's data outside of the network.

As Chris pointed out a remote wipe would definitely be desirable. You could put in logic so that if the device ever attempts to read the data while not connected to the network, it wipes the data (this might lead to unintended wipes). Blacklisting is good too, so that if the device tries to reconnect to the network, you can essentially brick it. One thing that would be really bad is if you have a network outage, and all your devices accidentally get wiped.

独守阴晴ぅ圆缺 2024-11-01 15:07:07

任何网络都可以复制另一个网络的 SSID,因此这是不可靠的。您可以开始使用已知路由器的 SSID 和 MAC 地址的组合,但 MAC 地址可能会重复(尽管不在同一网络上),因此这也不起作用。

坦率地说,除非有问题的无线网络使用证书来识别设备,否则您将没有可靠的方法来做到这一点,即使如此,这也假设您的应用程序中有一种方法可以获取使用 WiFi 网络在网络期间返回的证书验证。

Any network can duplicate another's SSID, so that's not reliable. You could start using a combination of SSID and a MAC address of a known router, but MAC addresses can be duplicated (although not on the same network) so that doesn't work either.

Frankly, unless the wireless network in question is using certificates to identify devices you're going to have no reliable way do it it, and even then this supposes you have a way in your application to get the certificate used the wifi network returns during network authentication.

忘羡 2024-11-01 15:07:07

也许您可以使用 IPSec 隧道。许多路由器和防火墙支持 IPSec。我的想法是这样的:

                             ----------------------------------- 
                            /            IPSec tunnel           \
                       +---------+                               \
                     A |  IPSec  | B      Untrusted               \
trusted network -------| capable |-------  Networks  ----------- Your application
                       | router  |      Internet, etc.
                       +---------+

为可信网络提供访问的网关路由器/防火墙在其自身和您的应用程序之间配置了 IPSec 隧道。在路由器和应用程序服务器上,隧道看起来就像另一个网络接口。路由器上的路由将应用程序的流量引导至隧道接口。可以在路由器上使用过滤器来确保流量仅在到达接口 A(即可信网络)时才转发到隧道。到达接口 B 并发往您的应用程序的流量可能会被路由器上的过滤器丢弃,因为它显然走错了路。

如果您的应用程序将其侦听套接字仅绑定到隧道接口,您就会知道您只接受通过隧道接收的连接。

您可以使用所需的加密和身份验证机制的任意组合来确保流量安全。大多数 IPSec 实现几乎支持您想要的任何内容。

Perhaps you could use IPSec tunnels. Many routers and firewalls support IPSec. What I'm thinking is something like this:

                             ----------------------------------- 
                            /            IPSec tunnel           \
                       +---------+                               \
                     A |  IPSec  | B      Untrusted               \
trusted network -------| capable |-------  Networks  ----------- Your application
                       | router  |      Internet, etc.
                       +---------+

The gateway router/firewall that provides access for the trusted network has an IPSec tunnel configured between itself and your application. On both the router and your application server, the tunnel looks like another network interface. A route on the router directs traffic for your application to the tunnel interface. A filter can be used on the router to ensure traffic is forwarded to the tunnel only if it arrives on interface A (i.e. the trusted network). Traffic arriving on interface B destined to your application can just be dropped by a filter on the router since it's obviously going the wrong way.

If your application binds its listening socket to just the tunnel interface, you'll know you're only accepting connections received over the tunnel.

You can use whatever combination of encryption and authentication mechanisms you want to to ensure the traffic is secure. Most IPSec implementations support just about anything you could want.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文