使用公钥/私钥对作为交付证明

Question

问题

我正在开发一个移动应用，其中user A应该物理将某些内容递送到user B，并且用户A必须证明已交付它。< / p>

有一个限制：

• 用户A或用户B在发送时可能处于脱机状态，因此无法依赖互联网连接

我的方法

我考虑过使用加密技术来解决这个问题：

安排交货时，会发生以下过​​程：

1. 生成密钥对，并将其存储在数据库中。
2. 私钥属于User B，应该转移到他的移动应用程序。
3. 某些well-known+delivery_uuid字符串使用公钥加密，并传输到User A。
4. 用户A的目的是仅在交付时显示加密代码（以QRCode的形式）。
5. 用户B的目的是在发送时使用移动应用程序读取QRCode。
6. 由于加密邮件以well-known字符串开头，因此User B移动应用可以对其进行解密并验证邮件是否正常。如果有效，应用程序会存储delivery_uuid部分，并在用户上网后立即发送到服务器端以便跟踪。
7. 如果User B试图伪造delivery_uuid，则显然不匹配。
8. 如果User A试图伪造QRCode，则User B的应用将无法验证该消息。

的关注

1. 每条加密邮件上都有well-known条的事实会使它变弱吗？考虑到密钥对只使用一次。
2. 任何人都不应该看到公钥。只有后端必须使用它来创建传递证明消息。同样明显适用于delivery_uuid
3. Sh * t发生了。如果用户B移动应用程序在将delivery_uuid发送到后端之前以某种方式崩溃并丢失user B，那么user A将需要依赖ACF诚实。
4. 我的钥匙必须有多强？考虑到包裹的货币价值很低。在这种情况下，RSA是更好的加密吗？

我真的知道这个问题很复杂，但如果有人可以帮助我，我真的很感激。

注意：我不确定Stackoverflow是否是正确的stackexchange社区询问此问题，如果它是offtopic，请发表评论。但由于它有关于逻辑的东西，我认为这是正确的地方。

Answer 1

似乎有点复杂。为什么不

1. UserB（以及安装应用程序以接收交付的每个用户）都会获得公钥/私钥对。私钥仅由UserB持有;如果它丢失，可以发出一对新的。同时，公钥是公共的，并与UserB的身份一起存储在数据库中。

2. 收到交付后，UserB会生成一个简单的文本文档，其中包含日期和时间，QRCode，接收包的人的姓名或所需的任何信息。该文档还包含公钥。任何格式都可以。

3. UserB使用其私钥对文档进行签名，并将签名附加到文档的末尾。现在你有一份明文文件，说明发生的一切，并证明UserB同意了。

4. UserB与UserA共享文档，和/或将其上传到需要的任何地方，例如记录系统。 UserA和UserB都可以保留脱机副本。

5. 如果需要递送证明，UserA只需要生成签名文件。

Answer 2

如果我理解正确的问题，这里有三方：

• 验证方，这是你的后端。
• 卖方，即用户A.
• 购买方，即用户B.

此外，我并不认为“任何人都不应该看到公钥”。他们应该是，这就是为什么他们被称为公众。

现在，为了确保物品已交付

• 用户A
• 致用户B，

我们可以进行以下设置。

1. 验证方（即后端）生成令牌，将其与买方，卖方，商品相关联并保留信息。
2. 验证方使用用户A（卖方）公钥加密令牌。
3. 验证方使用用户B（买方）公钥加密已加密的令牌。
4. 验证方将双重加密的令牌发送给用户B.由于它已使用用户B的公钥加密，因此只有用户B才能读取它。
5. 用户B使用其私钥解密双重加密令牌，并将结果保存在他的设备中。结果现在使用用户A的公钥加密，这意味着只有用户A才能读取它。
6. 当用户A来递送项目时，用户B将加密的令牌移交给确认。这可以通过QR码扫描完成。
7. 用户A使用其私钥解密加密的令牌并将其保留在设备中。
8. 每当可行（在互联网的可用性方面）向后端证明它时，用户A用后端的公钥加密令牌并将其一起发送到后端。
9. 后端使用其私钥解密加密的令牌，并在其持久性存储中进行查找，匹配买方和卖方，并完成验证。

Answer 3

使用签名而非加密。

0）分布式应用程序包含只有服务器知道的密钥对的公共部分。

1）安装应用的每个用户生成密钥对，保留私钥，并将公钥上传到数据库。

2）当计划交货时，服务器会生成交货ID并创建包含以下内容的消息：

• 送货ID
• 送货员（用户A）的公钥指纹。
• 收件人（用户B）的公钥指纹。

A将在发货前收到此消息和签名。 B可以，但在交付之前无需接收。

3）当A遇到B时，A可以将消息和签名离线转移到B.QR码很难，取决于密钥大小，但NFC肯定会起作用。 B可以验证服务器签名并知道该消息未被伪造或篡改。 A可以将他的公钥转移到B，B可以通过签名的消息验证其指纹。 A可以通过使用属于刚刚传输和验证的公钥的私钥创建签名来证明他是他所说的人。

4）B可以通过使用与传递消息中的指纹匹配的公钥创建签名来证明他是谁。如果A还没有它，B必须将他的公钥转移到A，A可以验证它是否与消息中存储的指纹相匹配。

5）B可以通过在消息上创建签名来证明收据（但是你想格式化）并离线传送给A.然后，A可以将此信息提供给服务器，服务器可以验证，因为它有B的公钥。

Answer 4

我们假设： - A有钥匙对。 - B持有交付UUID。 目标是使B能够提供只有A才能提供的证据。

如前所述，这可以通过数字签名来解决。你应该让B和A来交换必要的信息。 B应提供交货ID，A必须签字。

• 您需要持有合作伙伴的公钥。
• 您需要提供一种信息交换方式，也许是蓝牙？

我相信您可能需要的不仅仅是这个简单的协议。

Answer 5

在阅读答案后，我已经制定了解决问题的方法。我发布它作为回答知道每个人对其有效性的评论。

首先，让演员的名字简化：

• 用户A是卖家
• 用户B是买方

用例

1. 买方决定购买并付款。现在，他与卖家交谈以结合交付。
2. 付款确认后，后端会生成transaction_id，并将其与delivery_uuid相关联。我们称之为delivery_uuid。根据业务逻辑，只有买方可以访问它。
3. 买方应用请求delivery_uuid到后端，这会生成包含transaction_id和{{1}的消息然后对此消息进行数字签名。让我们称之为delivery secret
4. 买方应用会将此消息保存在存储中。
5. 当卖方和买方都满足，并且买方检查产品是否正常时，他会使用QRCode或NFC提供delivery secret。
6. 手中有delivery secret，卖家的应用可以检查delivery secret真实性（使用应用程序的公钥），然后存储它以发送到一旦有互联网接入，后端作为交付证明。
7. 现在后端具有送货凭证，即向卖家付款。

考虑

买方签名消息

我认为没有必要，因为通过后端概念，只有买方可以访问delivery secret。如果delivery secret泄露，我当然会遇到更大麻烦。

卖家签名

也没有必要，卖家唯一关心的是他需要将delivery secret发送到后端。如果他松开手机，这不是我们的问题。如果应用程序崩溃且delivery secret丢失，那么我们就会遇到问题。

服务器签名

此签名允许卖家确保delivery secret

• 属于正确的交易，阻止买方使用其他交易中的真实delivery token。
• 拥有有效的delivery_uuid
• 确保delivery secret仍然有效（我们可以为其添加有效性）