Bảo vệ bản sao, bảo vệ trí tuệ và các vấn đề triển khai


10

Sau một thời gian sử dụng Raspberry Pi 2 Model B v1.1., Tôi có lo ngại gì sau đây không?

  1. Tôi biết nó được tập trung để tăng cường các lĩnh vực giáo dục dễ bị tổn thương, nhưng có thể bán một sản phẩm, dựa trên RPi?. Để kiếm tiền với nó ?. Trở thành tỷ phú với nó?.
  2. Tôi nên bảo vệ sự phát triển như thế nào , giả sử, tôi không muốn ai đó lấy Thẻ SD RPi của mình, sao chép nó và có bản sao của riêng mình ?. Thay thế hiện tại của tôi là lấp đầy cổng SDCard bằng superglue :). Một lựa chọn khác có thể khiến RPi ping máy chủ cấp phép trực tuyến, tất nhiên sẽ yêu cầu kết nối WiFi . Hoặc ID HASH Phần cứng (Đây sẽ là câu trả lời tốt hơn tôi đoán ...)
  3. Tôi đã kiểm tra cũng có các cơ chế để khôi phục cài đặt ngay cả khi bạn không có quyền root, bằng cách gắn Thẻ SD. Một lần nữa, giải pháp tốt nhất của tôi là cách tiếp cận superglue ....

Cảm ơn trước.


2
Đây là một câu hỏi nhúng Linux chung. Đây là một vấn đề phức tạp cả về kỹ thuật và pháp lý.
Craig

2
Xin chào và chào mừng đến với RaspberryPi.SE! Đây là quá nhiều câu hỏi trong một. Một số vấn đề cũng rất rộng và không cụ thể về Pi. Bạn cần xem xét rằng thời gian và nỗ lực nhất định tất cả các hệ thống bảo vệ bản sao có thể bị phá vỡ. Đặc biệt là nếu hệ thống của bạn được triển khai và bạn không có cách nào ngăn chặn "kẻ xấu" sử dụng tất cả các công cụ có sẵn để phá vỡ sự bảo vệ của bạn.
Ghanima

@craig: Có Cộng đồng Linux nhúng không?
Brethlosze

WRT # 2: Bạn không thể ngăn chặn vi phạm bản quyền về mặt kỹ thuật trên bất kỳ nền tảng nào, tất cả những gì bạn có thể làm là chống lại nó một cách hợp pháp . Tôi nghĩ rằng bạn có giỏ hàng trước con ngựa ở đây. Vào thời điểm bạn có một dự án phần mềm dựa trên pi mà điều này là một mối quan tâm, bạn sẽ nhận ra không có dự án dựa trên pi nào thực sự bị ràng buộc với pi. Nó chỉ là một thiết bị có mục đích chung và cộng đồng được định hướng phát triển.
goldilocks

2
Đó không phải là "nền tảng của họ", phát triển ứng dụng khôn ngoan và họ biết điều đó và không quan tâm. Đó không phải là "mục đích của họ". Đó là SoC Broadcom thực hiện kiến ​​trúc ARM. Không có bất cứ ai sẽ làm gì với một pi mà không thể được chuyển một cách tầm thường sang một loạt các thiết bị khác. Vì vậy, một lần nữa: Bạn có xe đẩy trước ngựa . Vào thời điểm bạn quan tâm đến vấn đề sở hữu trí tuệ có ý nghĩa hay tầm quan trọng nào, bạn sẽ hiểu những gì tôi đang cố nói với bạn ...
goldilocks

Câu trả lời:


6

Nếu bạn thực sự lo lắng về việc bảo vệ tài sản trực quan của mình thì bạn có thể kết hợp ứng dụng dựa trên Rapberry Pi của mình với một số bộ điều khiển vi mô tùy chỉnh bên ngoài (MCU như AVR, PIC, 8051 ...) (được kết nối với Pi qua USB, RXTX, I2C, SPI, 1 dây ...). Ví dụ, ứng dụng bên Pi tạo ra một số ngẫu nhiên được gửi đến MCU, được giải mã và gửi lại dưới dạng khóa mở khóa để giải mã một cái gì đó quan trọng. Sau đó, bạn có một số chức năng quan trọng được thực thi trực tiếp trong MCU (bạn chỉ cần truyền tham số và nhận kết quả từ MCU). Bạn có thể tưởng tượng làm thế nào điều đó sẽ gây khó khăn cho việc bẻ khóa cho một hacker theo mức độ lớn, vì kiến ​​thức của anh ta sẽ phải rộng hơn nhiều so với thông thường. Không có một sự bảo vệ hoàn hảo, nhưng nếu bạn thực sự muốn biến nó thành một thách thức thì đây có thể là một cách để đi.


1
Đây thực sự là một giải pháp tốt .... Tôi sẽ thử dùng khái niệm này ....
Brethlosze

1
Thật không may, giải pháp cho khóa phần cứng cũng giống như khóa phần mềm - chỉ cần loại bỏ phần vi phạm của mã, xây dựng câu trả lời đúng, v.v ... Vì vậy, các kỹ năng tương tự sẽ hoạt động đối với khóa phần cứng.
tomnexus 17/05/2015

2
Không phải nếu bạn đặt một số chức năng quan trọng vào khóa phần cứng và làm cho nó trở nên quan trọng đối với chức năng ứng dụng Pi của bạn. Vì chức năng chỉ tồn tại trong một bộ điều khiển vi mô, nên không có gì để loại bỏ ở phía Pi. Điều này không phải là không thể phá vỡ, nhưng khó hơn rất nhiều lần vì nó đòi hỏi các kỹ năng cao hơn nhiều so với việc bẻ khóa mã thông thường.
avra

1
Trong khi các mạch bên ngoài thực sự có thêm sự bảo vệ, những thứ này tốn rất nhiều tiền: nghiên cứu, tạo mẫu, sản xuất, thử nghiệm, thực hiện, bảo trì. Điều gì xảy ra nếu một cái gì đó xảy ra dọc theo dòng? Điều gì xảy ra nếu Raspberry thay đổi (các) giao diện của họ trong các mô hình trong tương lai? Nếu đó là một tuổi thọ ngắn hoặc một dự án sở thích, hãy thực hiện nó. Nếu đó là một sản phẩm công nghiệp / thương mại, có lẽ OEM là một đặt cược an toàn hơn.
EDP

5
  1. Tôi nghĩ đó là ý tưởng với mô-đun tính toán cùng. Nó không phải là một vấn đề để biến lợi nhuận.

  2. / 4. Tùy chọn superglue có lẽ là một sự đánh đổi tốt. Cuối cùng, bạn không thể đánh bại kẻ tấn công có quyền truy cập vật lý vào thiết bị. Hãy nhìn vào các máy chơi game có thể đã đầu tư hàng triệu vào cơ sở hạ tầng DRM và cuối cùng tất cả đều sụp đổ. Theo một tinh thần khác, bạn cũng có thể nắm lấy sự cởi mở và bán một phiên bản phát triển của sản phẩm của bạn và bao gồm một số loại SDK. Phản hồi bạn nhận được từ một nhóm người dùng tập trung kỹ thuật có thể có giá trị và làm việc theo sở thích của bạn.


Tùy chọn superglue có lẽ là hoàn toàn hạt dẻ, nhưng bạn thực hiện một số điểm tốt khác ở đây. ; |
goldilocks

Trên thực tế, tôi đã suy nghĩ về một số ID phần cứng từ Raspberri Pi, để mọi phần mềm RPi có thể được lập trình cho mọi thẻ RPi, và do đó, nếu tôi sao chép phần mềm, hệ thống sẽ không hoạt động. Các uProcessors cũ, được lập trình đơn giản trên tàu, do đó bạn không thể rút phích cắm :).
Brethlosze

1
Ngay cả khi bạn có ID phần cứng, bất kỳ ai khác có quyền truy cập vật lý đều có thể đọc được. Bộ xử lý được lập trình trên tàu tất nhiên cũng cung cấp giao diện gỡ lỗi, vì vậy bạn thực sự có thể đọc chúng. Trong các hệ thống tinh vi hơn, SOC có thể sẽ chỉ đảm nhiệm việc thực thi mã đã ký. Tôi sẽ không quá ngạc nhiên nếu chip Broadcom có ​​một số chức năng theo hướng đó, nhưng bạn không có tài liệu cho nó. Nếu bạn muốn có kế hoạch bán hàng triệu đô la trên các đơn vị, họ có thể nói chuyện với bạn về điều đó;)
user1217949

LOL .. không, tôi đoán tôi sẽ bán một số lượng rất nhỏ trong số họ!. Vì vậy, nếu tôi có một mã chạy theo Raspbian, bất kỳ ai khác có thể lấy thẻ SD và đọc nó? gỡ lỗi nó? bẻ khóa nó? Tôi hoàn toàn chắc chắn, câu trả lời là tất nhiên có. Sự lựa chọn tốt nhất sẽ được Hardware Keyđề xuất bởi avra và chôn thẻ SD với SuperGlue bên trong đầu nối của nó?
Brethlosze

4

Mặc dù thực tế này chắc chắn là mất phạm vi bảo hiểm, nhưng bạn sẽ ngạc nhiên bởi số lượng đầu nối USB được dán trên máy tính để bàn trong môi trường văn phòng công ty. Và tôi đang nói về các tập đoàn đa quốc gia lớn ở đây.

Nhưng bây giờ về chủ đề ...

Đối với các dự án thương mại trong đó bảo vệ IP là một yếu tố chính, Pi tốt cho việc tạo mẫu / chứng minh khái niệm sớm nhất. Ngay cả khi bảo vệ sẽ không phải là vấn đề, việc triển khai Pi ở quy mô lớn hơn là IMHO không phải là giải pháp tốt nhất - vì một số lý do tôi đã mô tả trong một chủ đề trước đó trên diễn đàn này.

Không có hệ thống an toàn chống lại kỹ thuật đảo ngược / hack / sao chép. Bất kỳ hệ thống đều có thể khai thác. Mỗi hệ thống tuy nhiên có một điểm thâm nhập. Với cách tiếp cận mở và thẻ SD bên ngoài, Pi có tốc độ rất thấp. Một bảng phần cứng được quân đội thiết kế tùy chỉnh với SoC tùy chỉnh, các thành phần được kẹp và PCB đa lớp kết hợp với bộ tải khởi động tùy chỉnh, mã hóa phần cứng sẽ có điểm cao hơn.

Trên đó là yếu tố triển khai. Thị trường của bạn càng rộng, càng thú vị hơn khi mọi người đột nhập và đánh cắp công nghệ của bạn.

Nếu phần cứng là phần kháng cự của bạn trong toàn bộ thiết lập và bảo vệ công nghệ của bạn là yếu tố chính, tôi không nghĩ Pi là sản phẩm dành cho bạn. Nếu phần cứng của bạn là người hỗ trợ bán dịch vụ, có lẽ công nghệ bảo vệ nên được thực hiện ở phía máy chủ thay vì phía máy khách.

Chúng tôi sử dụng Pi để bán các dịch vụ như vậy. Phần mềm của chúng tôi trên Pi có mức độ bảo vệ nâng cao, chúng tôi đang sử dụng ứng dụng C đã biên dịch, bị khóa trên số sê-ri MAC và / hoặc CPU. Nhưng cuối cùng, không có phía máy chủ của chúng tôi, ngay cả mã nguồn cũng hầu như vô dụng.


3

Bạn có thể sử dụng một con heo đất bên trong quả mâm xôi với một khóa mã hóa. Có một vài thiết bị thương mại trên thị trường. Tôi đã sử dụng Phần mềm bảo vệ nối tiếp phần mềm này cho Raspberry Pi , hoạt động rất tốt.


2
Điều này sẽ không giúp bạn bảo vệ hệ thống khỏi nhân bản - tin tặc sẽ xóa kiểm tra khóa CT khỏi nhị phân của bạn nếu họ muốn ... Khóa CT sẽ chỉ cung cấp một mức độ bảo vệ nhất định (có thể để dừng sở thích cấp một tin tặc).
Kozuch

2

Làm cho nó thành nguồn mở

Nghiêm túc đừng cố gắng sao chép-bảo vệ nó. Làm cho nó nguồn mở. Nếu có thể, hãy để người khác tham gia dự án của bạn.

Sau đó tính phí dịch vụ. Bạn có thể kiếm được nhiều tiền nếu bạn làm đúng.

Red - đã làm điều đó như thế này và một vài công ty khác. Họ đang làm tốt và đang phát triển.


1
Không, đây là một sản phẩm, không phải là một dự án, không phải là một dự án lớn cũng không phải là một dự án lập trình rất thú vị. Âm thanh đẹp, nhưng một lần nữa, không.
Brethlosze

1
Tôi không đồng ý. Từ kinh nghiệm của tôi, mọi chương trình tôi đã viết được vận chuyển và sử dụng tích cực bởi khách hàng sẽ có các cuộc gọi hỗ trợ, yêu cầu nâng cao và tất nhiên là sửa lỗi. Phần mềm duy nhất không có bất kỳ phần mềm nào là phần mềm mà sau khi vận chuyển nó không bao giờ được sử dụng.
MadMike


Đó là điểm, đây là cho một sản phẩm, một thiết bị. không có nghệ thuật nào trong phần mềm, nhưng, cách thức xử lý các biến được bảo vệ, giống như bất kỳ bộ điều khiển thông minh nào. Bạn không có ý định mở nguồn phát triển của mình theo nghĩa đó, đó là vấn đề, đó là một loại công việc khác. Có thể bạn đang ở trong một công ty và bạn bực mình khi khách hàng gọi cho bạn, khi thực sự nó cung cấp cho bạn nhiều hóa đơn hơn cho sếp của bạn và cung cấp cho bạn dịch vụ bán hàng qua bưu điện, về lâu dài là tốt. Trong mọi trường hợp, nguồn mở là tốt cho nhân loại, không phải để kiếm lợi nhuận.
Brethlosze

1
Một lần nữa, đây là cuộc thảo luận không tưởng về việc tặng tất cả công việc của bạn vì lợi ích của con người hoặc tính phí mọi người cho mọi việc bạn làm.
Brethlosze

1

Vài xu của tôi:

  1. Không bao giờ tạo ra một giải pháp xung quanh các tập lệnh có thể được đọc trực tiếp.
  2. Phân tích chức năng về nhiều phần mềm / quy trình và phần cứng.
  3. Thêm một số phụ thuộc "chức năng" đọc phần cứng.
  4. Thêm đầu đọc thẻ thông minh và bán thẻ thông minh "enabler" với sản phẩm của bạn.
  5. Có máy chủ cấp phép
  6. Có bộ đếm sử dụng trong EEPROM !!! Và nên có một số cách để "nạp tiền" trực tuyến .. ;-)

...


1

Là một bảo vệ cấp mục nhập, có một ID thẻ SD duy nhất được tìm thấy theo /sys/block/mmcblk0/device/đó không được sao chép bằng phần mềm nhân bản hình ảnh đĩa điển hình. Điều này có lợi thế là không yêu cầu một thiết bị riêng biệt để giữ ID duy nhất và hoạt động khá tốt như một lớp bảo vệ thứ hai sau siêu lớp. Nó ít nhất sẽ ngăn chặn những người có khả năng nhân bản thẻ SD.

Một mẹo khác liên quan đến bảo vệ bằng ID là tránh sử dụng một kiểm tra đơn giản, tức là

if(readID() != 0xDEADBEEF) exit();

Kiểm tra đơn giản như thế rất dễ để khám phá (bằng cách tìm kiếm ID đã biết hoặc bằng cách theo dõi các cuộc gọi đến exit()) và xóa. Một cách tiếp cận tốt hơn nhiều là liên quan đến ID như một hằng số trong tính toán. Đó là, thay vì i++một nơi nào đó trong mã của bạn, bạn sẽ viết

i = i + readID() - 0xDEADBEEF + 1;

Điều này sẽ khó khám phá hơn nhiều, vì ID chính xác sẽ không xuất hiện trong nguyên văn mã của bạn ( 0xDEADBEEF + 1 == 0xDEADBEF0) và kiểm tra tất cả các cuộc gọi exit()cũng sẽ không tiết lộ vị trí của mã bảo vệ của bạn. Thay vào đó, mã của bạn sẽ đơn giản gặp sự cố trên một hệ thống có ID sai và kẻ tấn công sẽ phải gỡ lỗi logic của ứng dụng của bạn để hiểu và khắc phục sự cố.


0

Sử dụng một thành phần bên ngoài, tôi có nghĩa là thành phần bảo mật sẽ giải quyết vấn đề đó. Nếu bạn thực sự nghĩ rằng ý tưởng của bạn là tuyệt vời và đáng giá thêm chi phí để làm như vậy, tôi sẽ đề nghị bạn sử dụng một số MCU / CPU chuyên nghiệp để làm như vậy. Giống như dòng Broadcom BCM58101, không thực sự hiệu quả về chi phí và không thân thiện với người dùng mới nhưng mức độ bảo mật cao cũng có thể bảo vệ ý tưởng / thiết kế của bạn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.